Documentation Level: 
Intermediate
Documentation Status: 
No known problems

Backdrop Core Backups

Backdrop 1.30.0 introduced the ability to create a backup as part of running update.php. When updating to a new version of Backdrop, system updates need to be run by visiting core/update.php. If you have not configured your site for backups, the Backup step will be disabled like this:

Screenshot showing a message indicating backups are not configured on update.php.

Enabling or Disabling Core Backups

To enable backups as part of the update.php process, add the following line to your site's settings.php file: 

$settings['backup_directory'] = '../backups';

It is recommended to store the backup directory outside of the web root so the files are not accessible publicly. If putting the directory outside of the web root is not possible, use a random directory name such as: 

$settings['backup_directory'] = 'files/backups_' . md5(serialize($database));

Backdrop will put in place a secondary defense mechanism with an .htaccess file that stops web traffic from accessing the specified directory. However, this only works on Apache and Litespeed web servers. Again, it's recommended to store backups outside of the web directory. 

It is also possible to entirely disable core's backup functionality by setting to the boolean value FALSE. This will hide the Backup step in update.php for site owners that use an alternative backup strategy. 

$settings['backup_directory'] = FALSE;

Once a backup directory has been specified, the Backup step within update.php should be enabled.

Screenshot showing the "Create backup" button is enabled as a part of update.php.

Using Core Backups

Simply click the button to create a backup. Creating a backup takes longer depending on the size of your database. If the backup takes more than 20 minutes, the process will time-out. You may want to use an alternative backup method if your site has a database this large. Note that the progress bar may not increment and stay stuck one step for a long time, this is because the database backup is a single step.

Backups will be saved to the backup directory specified in settings.php. The created directory for the new backup is named with the date it was created. Inside of the directory are typically 3 files:

  • db_default.sql.gz: The database backup.
  • config_active.tar.gz: The configuration backup
  • [backup-name].backup.json: A configuration file indicating the contents of the backup and how it was created. 

If using Database configuration storage, the configuration backup is omitted, because the database backup already contains the configuration.

To restore the backup, see the Restoring backups documentation.

Backdrop core backups are a convenient and simple tool to create backups when you need them most: when updating your site.

Regular Interval Backup Strategies

Besides update backups, you should also create backups at regular intervals. Backdrop core does not yet provide a mechanism for regular backups, so you should investigate alternatives, such as the following.

Backup and Migrate Module

Backup and Migrate module is one of the most popular Backdrop modules. It has many capabilities such as:

  • Scheduled backups
  • Download and upload backups
  • Backups for not only database and configuration, but also the files directory and site code

Hosting Provider Backups

Nearly all hosting providers have some ability to create a backup. Find the documentation for your particular hosting company. Common tools like cPanel also include the ability to create backups.

Command Line Tools

The bee command line tool for Backdrop can export the database and configuration easily: 

bee db-export
bee config-export

The database can also be backed up with mysqldump, which can be faster than other solutions, but the configuration may need to be backed-up separately.

General backup best practices

  • Always back up the entire site before updating or upgrading. Backdrop core's backup ability can help with this.
  • Date your backups. Save each one into a directory or file with a title that includes the date of the backup.
  • Save a copy of each backup in a different location than your webserver.
  • In addition to your web host's backups, routinely do it yourself. Periodically run a separate backup monthly, weekly, daily or whatever fits your site's needs. Gauge the backup cycle by how much of your user's data you can afford to lose without impacting your site's visitors.
  • Document and test your backup and restore procedure before you need it.

The forum and Zulip chat are full of people who want help if you have questions about creating backups.