User friendly site backups with the Backup and Migrate suiteUser friendly site backups with the Backup and Migrate suite
As a designer I often feel out of my element whenever I have to crank open an FTP client (or even command line) into my site to perform file backups on a regular basis. It gets worse when you have to perform database backups, you usually have to use a third party tool like phpMyAdmin which leaves the uniformed user open to making tragic mistakes. No one ever wants to have the sinking feeling of attempting to restore from a faulty backup.
Do you know what all of this means? If not, it's time to find an easier solution.
To alleviate these issues, there is a suite of modules you can use to backup both aspects of your Drupal site. The great thing is that you can make your backups all within the context of your admin login, meaning the days of having to use your hosting panel to make backups could be over. Today I'm going to go over some basic implementations of the Backup and Migrate module. Note that some of these require certain Apache modules. That may mean that you have to have direct access to your server, however many of the crucial functions are out of the box.
Before you start, one caveat
Go ahead and install the Backup and Migrate module and enable it. There is one step you need to do before proceeding. You need to make a full backup of your entire site web root. This means you will have to FTP in and copy all of your files and directories to your local hard drive. Either throw them in a folder or ZIP / RAR / TAR and store it in a safe place. This is a master copy of your site with all the core modules, themes, etc that you are using. If you are a slightly more technical user you can save a little time by noting which exact Drupal version you are using and simply backup your /sites directory. Either way, stash it in a safe place (preferably backup up). The Backup and Migrate does wonders, but you should always keep a master copy of your site in case disaster strikes.
Manual database backups
Many people prefer to use their host's built-in panel tools or FTP for file backups, so let's take the most basic implementation of Backup and Migrate first. Enable the module and go to your admin menu Configuration -> System -> Backup and Migrate. You may see a warning dialog at the top if you didn't set a private file directory in Drupal, you can ignore this for now. The important thing to note is that you have literally no further configuration to make a backup. Simply hit the "Backup now" button and save the database to your hard drive. That's it.
Restoring a database
Did you accidentally nuke half of your content? No problem, simply go to the "restore" tab and upload a backed-up version of your database. For good measure, peel open the advanced settings and check the box to take your site offline, then click "restore." It's as simple as that.
The second crucial component of a Drupal backup is the contents of your sites/default/files directory. This is where all your uploaded content is stored. To provide backups for files you need to make sure your host server has PEAR and the archive_tar library. If you have those installed, lucky you, install Backup and Migrate Files and enable the module. After that there really isn't much you have to do, when making a backup you will be able to select a directory to backup in addition to the regular database backup option.
Let's take it to the next step and alleviate the need to do things manually. Go to the "Schedules" tab and click to Add a schedule. Check the box to enable and select the time between backups. For good measure you can select to keep a specified number of backups. If you think you may run into space issues on your host you can set this to prevent a ballooning files directory.
Remember that backups are only as safe as the machine they are being stored on. If you are backing up to your own site server and the server dies, all your backups go along with it. To prevent this you can use some additional modules and services. One easy way is to enable email backups. Under the "Destinations" tab click "Add destination", then "E mail".
If you have another server, you can select alternative FTP (or SFTP) servers. After you have added your new destinations you can change any automatic backups to use these alternative destinations.
The default module has built-in support for NodeSquirrel, which is the module author's own service. For $5 a month you get offline backups for 1 site. To configure this you simply set your Key in the given field and select your backup destination to their service.
What's this about migrating?
For some reason I never seem to have much luck migrating my Drupal databases between hosts, or between my local Drupal installations and my online ones. Differences between phpmyadmin versions in respect to default settings can cause a migrated site to appear as long string of error messages, or even the dreaded "white screen of death." In this case you are in for a fun day of troubleshooting. Alternatively you can use Backup and Migrate to move your database, a technique that has never failed me.
Your process for migrating should look something like this:
1. Backup your current site files
2. Backup your site database using Backup and Migrate
3. Copy site files to your new host
4. Install Drupal on your new host as you would normally
5. On the newly installed site, go to Modules and enable Backup and Migrate
6. Restore the database from your backup
Your site should be up and running exactly as it was before. You may have to clear your caches under Configuration -> Performance. Site migration really doesn't get much easier than that!
According to the module maintainers, there is some support for the AES module but it is still in the experimental phase. If you are really worried about your database and site security you should look into that module. For the majority of users, using good security practices in respect to FTP access / drupal admin permissions and strong passwords should be enough to give you a reasonable level of security. One important thing to note is that on-site backups need to go into Drupal's private files directory and that directory should not be accessible via the web. You can check your settings at /admin/config/media/file-
Using off-site backups instead of on-site backups can give you an additional layer of security in case your FTP is compromised. Always remember to use different passwords for everything, using the same password for your database, FTP, and Drupal login is going to be problematic (obviously).