Making File System Backups

The database backup is only half of the backup equation. Without the files stored on the server, your site can never be completely restored after a disaster. The files in question fall into two general categories: those used by Drupal to run and present your site, and those uploaded to the site as content.

The files in the first category include the scripts that were delivered with the Drupal installation, contributed modules that you may have installed, customized themes, and the configuration file (settings.php). From the standpoint of a backup strategy, these files are relatively easy to deal with. Their volume doesn't increase even as site traffic grows, and you know every time they change since you make the changes yourself. If you simply take the time to manually copy these files to your local machine every time you install something new or make a change, you're already ahead of the game.

The files in the second category—the files uploaded as content to your site—can be more problematic. They can change regularly as your site visitors upload more and more content, and their volume can become quite large. (My personal blog, for example, amassed 1GB of images in slightly over a year of operation.) The strategy for making backups of these files must be different from the strategy for backing up script files, because of the frequency of change and because of the practical limitations of moving large masses of data across the network.

The Filesystem Backup module and the GNU/Linux cp command are two tools that you can use to make file system backups.

0 0

Post a comment