Drupal backup restore test — why "backup exists" is not enough

A backup that has never been restored is an untested hypothesis. Here is how to make sure your Drupal backup actually works.

A backup is a promise, not a guarantee

Nearly everyone has a backup. Hosting providers take nightly snapshots, some use mysqldump scripts, others rely on modules like Backup and Migrate.

But the question is not whether a backup is being made — the question is whether it works. A backup that has never been restored is an untested hypothesis.

A restore test is simple: take a backup and restore it. See whether the result is a usable site.

What a backup must contain

A complete Drupal backup consists of two parts:

Database — all Drupal content, configuration, users. Without the database there is no site.

Files — the sites/default/files/ directory. This is where images, documents and uploaded files live. This part is sometimes forgotten in backups.

Additionally you should preserve:

• composer.json and composer.lock — dependencies
• settings.php (securely, separately) — database password and configuration
• .htaccess and other configuration files

How a restore test works

1. Create a test environment

Do not restore directly to production — restore tests are done in a separate environment.

Options:

• Local development environment (ddev, DAMP, WAMP)
• Staging server
• Temporary subdomain on hosting

2. Download the backup

First check the backup file size — if it is much smaller than expected, something may be missing.

ls -lh backup_2025-01-02.sql.gz
# Expected size depends on site volume — smaller than 1MB is suspicious

3. Restore the database

# Extract
gunzip backup_2025-01-02.sql.gz

# Restore to MySQL database
mysql -u drupal_user -p drupal_db < backup_2025-01-02.sql

# Via Drush
drush sql:drop && drush sql:cli < backup_2025-01-02.sql

4. Restore files

# Extract files
tar -xzf files_backup_2025-01-02.tar.gz -C /path/to/drupal/sites/default/

5. Adjust settings.php

The test environment has different database credentials. Edit settings.php:

$databases['default']['default'] = [
  'database' => 'test_drupal_db',
  'username' => 'test_user',
  'password' => 'test_password',
  'host' => 'localhost',
  // ...
];

6. Run Drupal updates

drush updb
drush cr

7. Verify the result

• Does the homepage load?
• Are images visible?
• Can the admin log in?
• Do critical functions work?

If everything works — the backup is good. Document the result.

Common problems during restore testing

Database is empty or corrupt — the mysqldump file is broken. Cause: disk ran out of space, process was interrupted. Solution: check backup creation logs.

Files missing — the backup script did not include sites/default/files/. Solution: check backup contents with tar -tzf backup.tar.gz | head -20.

Site errors after restore — version mismatch (backup from old Drupal, restoring to new PHP version). Solution: also restore the codebase along with the database.

Backup is too old — the nightly backup is gone and only a week-old backup is available. Solution: check retention period and frequency settings.

How often to test

• At least once per quarter — automated backup does not mean automated functionality
• After major Drupal updates — ensure the backup format remains compatible
• Before planned major changes — confirm there is a working backup to return to

Backup best practice

• 3-2-1 rule: 3 copies, 2 different media, 1 offsite — e.g. server + S3 + local
• Separate server: if the server is hacked or burns down, backups must be elsewhere
• Encryption: backups contain database passwords and user data
• Retention period: minimum 30 days — sometimes a compromise is noticed late

As part of our maintenance service we keep an eye on backups too — read about Drupal maintenance.

Kaido Toomingas WebPro Company OÜ

Need Drupal help?

If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.

Contact us