Drupal backups with Backup and Migrate: what it protects and when you need it
Backup and Migrate is a contributed Drupal module that packages a site's database and files into archives that can be scheduled, stored in more than one place and restored, so a team can recover content and configuration without rebuilding them by hand. You need a scheduled, offsite and tested routine as soon as the site holds editorial work, user records, form submissions or configuration that someone has spent time tuning and cannot quickly reproduce. A single manual copy taken before a release is not enough for a production site that changes every day. Confirm the module's current capabilities, supported Drupal versions and any database or storage destinations on its Drupal.org project page before you design around them, because the feature set changes between releases.
A Drupal site has two stateful parts: a database, which holds nodes, users, revisions, menus, configuration and most custom entity data, and a files directory, which holds uploaded images, documents and generated derivatives under the public and private file paths. Both must be captured from the same point in time, or a restore can bring back a database that references files that no longer exist. Code, custom modules, themes and the Composer lock file should not depend on the backup at all. They belong in version control and a build pipeline, so a restored environment is rebuilt from known source and only the data is recovered. Ask your team which of these is true today, because a site that keeps patched core or theme files only on the server has a recovery gap that no backup archive closes.
Backup and Migrate or infrastructure snapshots: which fits which site
This table compares the contributed Backup and Migrate module, database-native dumps run on a schedule, and infrastructure snapshots taken by the cloud platform or hypervisor. Read each row against your own hosting layout, since most production sites need a Drupal-aware backup alongside snapshots rather than one method alone.
| Capability | Backup and Migrate module | Database dumps on a scheduler | Infrastructure snapshots |
|---|---|---|---|
| What it captures | Database, public and private files, and selected configuration through the Drupal interface or Drush | Database only, unless paired with a separate file copy job | Whole disks or volumes, which can include the database, files and server state |
| Where copies go | Local storage or configured remote destinations, depending on the module setup you confirm | Wherever the script writes, usually a local path that you copy offsite | Stored in the cloud or hypervisor snapshot service, often in the same account or region |
| How restores are done | Restore through the module or Drush on a matching Drupal codebase | Import the dump with the database engine's client, then restore files separately | Restore the volume or instance, which returns the full machine state at that point |
| Consistency of database and files | Captured in one run, so the set is usually aligned | Only as aligned as the separate file job, so timing gaps are possible | Crash-consistent unless the database is quiesced first, so confirm your method |
| Works across database engines | Follows the supported MariaDB, MySQL, PostgreSQL or SQLite choices in the system requirements, confirm the engine for your version | Engine-specific tools, so each supported database needs its own procedure | Independent of the database engine, since it copies the storage layer |
| Restore to a different host | Suited to moving a site to a new environment when the codebase matches | Possible but manual, and file paths often need editing | Usually tied to the same platform or image type, so cross-cloud restores need planning |
| Best fit | Sites that need granular restores of content, files or configuration, and a reliable Drupal-aware record | Small sites with a simple database and a separate file backup routine | Teams that already run snapshot policies and need machine-level recovery |
| Recommended combination | Scheduled Drupal backups as the primary restore path, with encryption and offsite copies confirmed | Acceptable only as a stopgap with tested restores | Snapshots as a second layer for disaster recovery, validated against the Drupal backup |
What a complete Drupal backup must capture
A restorable Drupal site needs four parts captured together: the database, the public and private files directories, the environment and secrets, and the code and exported configuration held in Git. Backup and Migrate covers the database and the files directories, but it does not cover the rest. The settings file that holds database credentials, hash salt and file paths, along with any values held in an external secret store, must be recorded separately and kept under the same access controls as the backup itself. Confirm in your own environment where settings.php, any settings.local.php and your secret store live, who can read them, and whether a restore can be performed without a developer rebuilding them by hand.
A database-only backup restores content, users, menus and configuration stored in the database, but it breaks every file reference. Images, documents and media entities point to paths in the files directories, so the restored pages render with missing assets and broken links. A files-only backup does the opposite: the assets come back, but nothing in the database points to them, so they are orphaned and the pages that used them do not exist. Both halves must come from the same point in time, or the restored site will mix content and media from different days.
The code tree and exported configuration are the third leg. Contributed modules, custom modules, themes and the Composer lock file should come from version control, not from a copy of the live server, so the restored site runs the same code it ran when the backup was taken. Confirm that your configuration is exported to the repository on every change, that the Composer lock file is committed, and that you know which Drupal core release and PHP version the backup was made against, since Drupal core release schedule dates determine when a restored site will need work to stay supported.
How to set up scheduled Drupal backups with checks at each stage
This sequence takes a Drupal site from version checks to a tested restore, so the database and files can be recovered into an isolated environment and the team knows the backups work before an incident forces the question.
Confirm Drupal and database versions
Start by checking the Drupal core version, PHP version and database engine (MariaDB, MySQL, PostgreSQL or SQLite) against the Drupal system requirements, and confirm the backup module release you plan to install supports that core version. The platform team or DeployOpen engineer records these versions in the runbook. The step is complete when the versions are written down and the module's compatibility statement on its Drupal.org project page matches them. If the site runs Drupal 7, stop here: backup module guidance differs and the site needs a migration decision first, as covered in the Drupal 7 end of life partner page.
Install the backup module with Composer
Add the Backup and Migrate module to the site's Composer project in a feature branch, then run the update through the standard build pipeline so the version is pinned in the lock file. Confirm the exact package name and any companion Drush commands against the module's current documentation, since command names can change between releases. The step is done when the module appears in the enabled module list on staging and the lock file change is committed for review.
Define what is included and excluded
Decide which database tables are exported in full, which are excluded (typically cache and session-style tables, after confirming each one is safe to rebuild) and which file directories are included, such as the public files directory and any private files directory outside the web root. Record the decisions alongside the site's configuration export. The check is a dry run on staging: the backup file's size and table list should match the written definition, and no secrets or regenerable caches should appear in it unexpectedly.
Set separate schedules for database and files
Configure one schedule for the database and a separate one for files, because the two change at different rates and may need different retention. Set times outside peak editorial activity and confirm they run through cron or a scheduler your team monitors. The step is verified when the scheduled runs appear in the backup module's log on staging and a missed run would generate an alert in your monitoring tool rather than fail silently.
Choose local and offsite destinations
Configure a local destination on the server for fast recovery, then an offsite destination in a separate account or region you control, using the storage types the module supports and your organization approves. Confirm access credentials are scoped to write backups only where possible. The check is that a backup written by the schedule lands in both destinations, and that the offsite copy can be listed and downloaded by the team member who would perform a restore.
Enable encryption with keys held outside the site
Enable encryption for backup files and store the encryption key in a secrets manager or sealed vault that is separate from the site and from the backup storage, so a copy of the backups alone cannot be read. Document who can retrieve the key and how it is rotated, and confirm the module's current key handling against its documentation. The check is that an encrypted backup cannot be restored without the key and that the key itself is recoverable from the vault by the named recovery owner.
Run a manual backup and inspect it
Trigger a manual backup of both the database and files on staging, then inspect the output: confirm the archive completes, the file size is plausible for the site, and the expected file directories are present. Keep a copy of the run log with the change record. The step closes when the manual backup and the first scheduled backup both appear in both destinations with matching timestamps.
Perform a full restore to an isolated environment
Restore the most recent backup to an isolated environment with no outbound email, no live integrations and no access from public networks, using the documented restore path for the module and Drush. Then check that the site loads, a logged-in editor can open a content page, a file reference in the media library resolves to an existing file, and cron runs without errors. Record the time the restore took and any manual steps required, and update the runbook with them. A restore that has not been run end to end is not yet a backup you can rely on.
Backup approach by hosting environment
On a virtual machine or bare-metal server running Apache or Nginx, the Drupal codebase, the sites/default/files directory and any private file path usually sit on the same local disk as the web server, and the database runs on the same host or a separate database server. Backup and Migrate can export the database and the file directories on a schedule, and it can write those archives to a local path or to remote storage the team configures. Infrastructure snapshots of the virtual disk can capture everything at once, but they only restore cleanly if the database is consistent at the moment the snapshot is taken.
- Database dumps: Schedule the module's database backup and confirm it runs against the production database user, not a read-only replica.
- File coverage: Check that public files, private files and any custom storage paths are all included, since the codebase itself is usually rebuilt from version control rather than restored from archives.
- Snapshot limits: A disk snapshot taken while MariaDB, MySQL or PostgreSQL is writing can produce a copy that needs repair, so pair snapshots with a logical dump or a database-consistent snapshot method.
- Offsite copies: Confirm that at least one copy leaves the host and the hypervisor or cloud account that runs it.
- Encryption keys: Store the archive encryption key separately from the backups it protects.
Confirm with your host or platform team whether snapshots are application consistent, how long they are retained, and whether a single file can be restored without rolling back the whole disk.
In a container or Kubernetes deployment, the Drupal application container is usually disposable, so the code comes from the image and the build pipeline. Persistent state lives elsewhere: the database is often a managed or stateful service, and public and private files may sit on a shared volume, a network file system or object storage through a contributed storage module. Backup and Migrate runs inside the Drupal runtime, so it sees only what the container can reach. Volume snapshots capture the storage layer but not the logic that ties files and database rows together.
- Where state lives: Map every path that holds user content, including any object storage bucket, and confirm which of them the module can archive directly.
- Object storage: Bucket versioning or replication is a separate control from the module, so confirm its settings with the storage owner.
- Volume snapshots: Check whether the CSI driver supports consistent snapshots and whether they are scheduled per volume.
- Restore target: Test restores into a new namespace so that the restored state is checked without touching production.
- Secrets: Keep the database credentials and encryption keys in the cluster's secret store, and back up their source definitions, not the secret values in plain files.
Confirm with the platform team which storage classes are backed up, how snapshots are scheduled relative to database writes, and who is responsible for restoring object storage.
On a managed Drupal platform, the provider typically runs the hosting stack, and the team may have limited access to the server or the database. The provider's snapshots and backup tooling often cover the database and files at the platform level, while Backup and Migrate may still be useful for producing site-level archives that the team can take elsewhere, restore to a different environment or keep under its own retention rules. The two mechanisms overlap, so the team should decide which one is the system of record for each recovery scenario.
- Provider coverage: Ask which components are included in platform backups: database, public files, private files, configuration and any external storage.
- Module role: Decide whether Backup and Migrate runs as a second, team-controlled copy, and confirm that the platform permits the scheduled task and the destination.
- Retention and access: Get the retention period and the process for restoring a single item in writing, along with any fees for restores.
- Portability: Confirm that exported archives can be imported into your own infrastructure if you change providers.
- Restore tests: Ask whether the provider supports a restore into a separate environment so the team can verify it.
Confirm these points against the written service terms before relying on the provider's backups as the only recovery path.
Protecting backup files, keys and access
A Drupal backup contains everything the site knows: the database, uploaded files and the settings that hold credentials. The cards below cover the risks that most often turn a backup routine into a data exposure, and the control and the question to confirm for each. Confirm each point with your security or compliance owner before the schedule goes live.
Unencrypted copies of personal data
A database dump includes user accounts, form submissions, order records and any other personal data the site holds. Backup and Migrate can encrypt backup files, and the encryption step should be part of the backup profile rather than a manual follow-up. Check that every destination, including local temporary folders on the web server, receives only encrypted archives.
Encryption keys stored beside backups
An encrypted archive is only protected while its key stays separate from it. If the key sits in the same bucket, the same server directory or the same repository as the backup, anyone who reads the backup can decrypt it. Store the key in a secrets manager or a restricted vault with its own access log. Confirm with the owner who holds recovery access and how a lost key would be handled.
Over-broad access to backup storage
Backup storage is often created by an infrastructure team and shared with developers, agencies or former staff. Limit write access to the service account that runs the backup, and limit read access to a named restore group. Remove credentials for people who have left the project. Ask the owner to confirm who can list, download and delete backup objects, and whether deletion is logged.
Secrets inside settings files
The Drupal settings file typically holds database passwords, hash salts, API keys for connected services and mail credentials. If the backup includes that file, every secret it contains leaves the controlled environment with the archive. Exclude secrets from the file backup, load them from environment variables or a secrets store, and rotate any credential that has already been copied into an older archive. Confirm the rotation plan with the platform owner.
Retention beyond policy
Automated schedules keep copies until someone removes them, so a backup taken years ago can still hold data that the retention policy requires you to delete. Set a maximum age and a maximum count per destination, and apply the limit to offsite copies as well as local ones. Ask the compliance owner which retention period applies to each data category and whether legal holds need a separate process.
Restores that skip access controls
A restored copy of a production site carries the production user accounts, roles and permissions. If that copy is reachable from a test address or has live integrations enabled, it can expose data to people who were never meant to see it, or send real emails and API calls. Restore into an isolated environment, disable outbound mail and integrations, and reset test passwords. Confirm the restore environment's access list with the owner before the first test.
Restore tests: proving a Drupal backup works before you need it
A backup is only trustworthy after a restore has been performed on a separate environment and the restored site has been checked. Until that happens, you have a set of files and a database dump, not a recovery capability. A restore test should run against a copy of the most recent database and file archive, restored to a non-production host with its own domain, mail routing disabled and outbound integrations pointed at sandboxes so that nothing it does reaches real users, payment providers or CRMs.
The check itself should cover five things. First, the site boots: the database connects, the codebase loads and the front page renders without fatal errors. Second, login works for a known test account, which confirms that user records and password hashes came back intact. Third, content and file references resolve: sample nodes render with their images and attachments, and the public:// and private:// file paths point at files that exist. Fourth, configuration matches what you expect, which you can confirm by running a configuration status check against the exported configuration in version control. Fifth, cron runs to completion, because scheduled tasks often expose missing queues, stale settings or broken credentials that a page load will not reveal.
Decide the test cadence and sign-off with the business owner, not only with the engineers running the backups. Your recovery point and recovery time targets determine how often a restore must be proven and how much drift between tests is acceptable, so ask the owner to state those targets in writing first. Record each test with the backup set used, the environment, the checks performed, the person who signed off and any failures. That record is the evidence auditors and incident reviewers will ask for, and it should be agreed before the first test, not reconstructed after an incident.
What to confirm in your environment before you rely on the setup
Backup and Migrate works only as far as the environment around it allows. The checks below cover the module, the database, the file store, the storage destination, the secrets and the restore layout, and each one has a named owner who should confirm it before the schedule is trusted.
Module release and Drupal compatibility
Confirm that the installed release of Backup and Migrate supports your exact Drupal core version and PHP version, and that no pending core or contributed update changes how the module behaves. Check the project page on Drupal.org and the release notes for the version in your lock file. The Drupal development lead should record the version in the runbook, because a backup module that breaks during a core upgrade fails silently until someone needs a restore.
Database engine and version support
Confirm which database engine and version your site runs, and whether the dump and restore path has been tested against that exact combination. Drupal supports MariaDB, MySQL, PostgreSQL and SQLite, so a dump taken on one engine may not restore cleanly on another. The platform or database owner should run a test restore into a clean instance and compare table counts and a few sample records against production.
Behavior with large files directories
Measure the size of the public and private files directories and confirm that the backup job completes inside its window without exhausting disk space or PHP memory on the host. Large media libraries often need the file archive to run outside a web request, through Drush or a scheduled job. The site owner should provide the current file count and total size so the backup window and storage estimate can be checked against real figures.
Private files and secrets handling
Confirm how the module treats the private files directory, the settings file and any stored credentials, and whether those items are included, excluded or encrypted in each backup. A dump that contains database passwords or API keys is itself a sensitive asset that needs the same access controls as production. The security lead should review the encryption setting, the key storage location and who can download a backup file from the interface.
Offsite transfer to your storage provider
Confirm that the destination you plan to use, such as an S3-compatible bucket or an SFTP server, is supported by the module or by a companion module, and that credentials and retention rules apply there. Test an end-to-end transfer of a full backup and download it again to verify the checksum. The cloud or infrastructure owner should confirm the bucket policy, versioning and region, because those settings decide whether a backup can be deleted or overwritten by mistake.
Restore runs in multisite and containers
Confirm how a restore is executed in your layout, including which database each site in a multisite install maps to, where the files directory is mounted, and whether the restore runs inside the container or on the host. Container images often lack the tools or paths the backup assumed, so a restore that works on a virtual machine may fail on Kubernetes. The platform engineer should run a documented restore drill on a copy of the environment and record the steps, timings and any manual fixes.
Questions teams ask before they set up Drupal backups
Can our own team set up Drupal backups with Backup and Migrate?
Yes, if your team already runs the Drupal site, has shell or Drush access to the hosting environment, and can manage storage credentials. Backup and Migrate is a contributed module, so the module setup itself is straightforward. The harder parts are deciding what to back up and how often, where the copies go, how they are encrypted, and proving that a restore works. Teams without an operations owner for the site often find the restore test is the step that gets skipped. A partner can run the setup as a fixed-scope piece of work, and your team keeps the documented routine afterward.
What drives the effort of a Drupal backup setup?
The main drivers are the size of the database and the file store, the number of sites, the hosting model, and the encryption and offsite requirements. A single site on one server with local storage is a small job. A multisite estate, a site with large uploaded media, or a platform that spans several cloud accounts needs more planning for schedules, storage paths and access. Encryption adds key handling work, and offsite copies add storage accounts, transfer rules and retention policies. Infrastructure snapshots, where your platform provides them, can complement module backups but need their own restore procedure.
What does the work need from our team?
Plan for access to the hosting environment, including the web root, the database and the cron host, plus credentials for the storage location that will hold the backups. You also need an owner for encryption keys, who decides where keys are stored, who can read them and how they are rotated. A staging environment is needed to run restore tests without touching production. Your team should also confirm who approves retention periods and who receives failure alerts. Ask the partner to list each access item before work starts so approvals can run in parallel.
How long does a first backup setup and restore test take?
The duration depends on the same drivers: the number of sites, the size of the data, the hosting model and the offsite and encryption requirements. Ask for a timeline in the written scope rather than relying on a general figure, and check that it covers the first full restore test on a separate environment, not only the configuration of schedules. Access approvals and storage account setup often take longer than the technical configuration, so ask how much of the timeline depends on your team's responses.
What recurs after the backup setup goes live?
Backups need routine attention after launch. Schedules should be checked when the site changes, when the hosting moves, or when new sites are added. Restore tests should repeat on a planned cadence, because a backup that has never been restored is unproven. Retention reviews confirm that the copies kept still match legal, contractual and business needs. Module updates to Backup and Migrate and to Drupal itself also need checks, since a Drupal upgrade can change what a restore requires. Decide in advance who owns each of these tasks and whether they sit inside a support retainer.
What should we ask for in a backup quote?
Ask for a written scope that lists each site, database, file store and environment included, the backup types (module backups, infrastructure snapshots or both), the schedule and retention for each, and where encrypted copies are stored offsite. Request the restore test plan, including what is restored, where, who signs off and what evidence is kept. Ask which tasks are one-time and which recur, and what a retainer covers. Confirm who holds the encryption keys, what your team must provide, and which assumptions would change the timeline. DeployOpen does not publish a price list, so the quote follows from this written scope.
Does DeployOpen certify that our backups meet a compliance standard?
No. DeployOpen plans, implements and documents backup controls and can prepare evidence such as schedules, retention settings, restore test records and access records for a compliance assessment. Independent auditors and certification bodies issue any audit report or attestation. Confirm with your auditor which backup evidence they expect before the setup begins, so the records are captured from the start.
How DeployOpen scopes and delivers Drupal backup work
DeployOpen plans, implements, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Drupal backups with Backup and Migrate, that means the backup design is written against your hosting, database and file layout, then built, restore-tested and handed over to your team.
How we scope
- Written scope lists the Drupal sites, databases, public and private file paths and environments covered by backups.
- Scope records the backup targets, schedules, retention periods and offsite locations your organization has approved.
- Scope states who owns restore decisions, encryption key custody and the acceptance test for a successful restore.
How we build
- Backup and Migrate configuration is set up on each site, with profiles for database and file destinations defined.
- Infrastructure snapshots, where used, are configured alongside the module so both methods are documented and reconciled.
- Encryption, offsite copy transport and access credentials are configured in your environment, with secrets kept out of the codebase.
How we hand over
- Runbooks describe each backup job, its schedule, storage location and the exact steps for a database or file restore.
- A restore test is run on a non-production copy and the results, timings and gaps are recorded in the handover pack.
- Your team receives access, alert routing and ownership notes so that backup jobs can be operated without DeployOpen.
How we support
- Fixed-scope engagements close at handover, with a written list of anything deferred or confirmed by your environment owners.
- Ongoing backup checks, restore rehearsals and module updates can be arranged as a retainer, scoped in writing.
- Backup configuration is reviewed when Drupal core or the Backup and Migrate module changes, and when hosting changes.
