Last updated February 17, 2016. Created on June 28, 2010.
Edited by hansfn, gdaw, rashid_786, tannerjfco. Log in to edit this page.

Creating and storing website backups is not just an element of website best practices, it is the most important step to ensure website stability and a requirement for all forms of development!

Basic advantages of a backup strategy

  1. If for any reason your website goes awry restoring it from a recent backup is sometimes the only option available.
  2. New development environments can be created and refreshed very easily.
  3. Upgrades and patches can be tested singly or in groups with high confidence when using a recent backup of your production site.

To create a complete copy of the website both the database and the custom files will need to be backed up. An automatic backup strategy is easy to implement using the Backup & Migrate module, and a manual backup can be created before major updates or new implementations, providing a convenient restore point taken immediately prior to the changes going in.

Backup & Migrate

The Backup & Migrate module facilitates emergency recovery and site migration. You can configure it for automatic backups saved to the filesystem - with more frequent backups during development.

You can also create a manual backup before undertaking any complex configuration changes or major updates. That way, you have a "restore point" in case of disaster.

While there may be some issues of security when you save the database and content as a file (you could exclude certain tables, perhaps), the benefits of having a rollback in case of disaster are significant.

The module also facilitates migration of the site. I just moved a complex site with Views, APK, CiviCRM etc., about 12,000 files. I moved the files, created a new database, edited settings.php and civicrm.settings.php for the new database, exported the database from the existing site and imported it in the new site's database with phpMyAdmin and VOILA - site moved! (sometimes I copy the files, make a default installation, enable the Backup & Migrate module, and import the database in the module interface - that works too).


Drush (Drupal Shell) is a command line utility written in PHP. To use Drush you need to have shell (SSH) terminal access to your server and be able to install and configure the Drush utility code.

Drush also integrates with the Backup & Migrate module.

Drush archive-dump

Drush archive-dump creates an archive of your files and database with the archive-dump command.

Drush sql-dump

Drush sql-dump uses mysqldump to back up your database. It is particularly effective when combined with Drush aliases so you do not have to be in your site directory, and you can backup a remote server db if you have SSH access on it.
Example sql-dump command (without alias) adding timestamp to filename:
drush sql-dump --result-file=PATH/TO/BACKUP/DIR/DBNAME_`date +"%m_%d_%Y-%H:%M"`.sql

Command line interface

If your webhost gives you access to the Command line: You can perform a database dump with the mysqldump command.

Looking for support? Visit the forums, or join #drupal-support in IRC.


guodskrap’s picture

Just a quick note that the Backup & Migrate module does not currently work with PostgreSQL databases. So while it is a good practice to backup your files and database(s), this module will not do that task for those using PostgreSQL.

decibel.places’s picture

azl123’s picture

I hope I've posted this in the appropriate place and am looking for some guidance. I'm new to Drupal.

I've got a Quickstart installation working and noticed some differences in files and permissions between and my live site domain directory. I'm wondering if these differences will create problems depending on if I use the live version of my Drupal site in Quickstart, or should I begin inside Quickstart and upload that version to my service provider. What are some recommended best practices?

My live site has .htaccess but after running drush, this file is not present on my virtual machine.
My live site has a database directory with database.4.1.mysql in it, Quickstart 1.0 doesn't have the database directory. Should I use drush to create a or is it customary to use example6 as the sandbox?
Also, permissions on my live site are more relaxed than in

My goal is to be able to add my content, customize my site in the Quickstart environment, then get that uploaded to my service provider. Is Filezilla a recommended means of doing this?

Thanks for any help or directing me to documentation I may have missed in researching this topic


decibel.places’s picture


This is not the correct place to ask these questions - but you said you are new to this community.

If your question is specific to the Quickstart project, you should search that project's issue queue, and if you don't find an answer you can create a "support" issue - but realize that the people that maintain these projects have limited time to answer general questions, so be as specific as possible.

If your question is more general about configuring Drupal post-installation, there is a forum for that here. It is good etiquette to search for an answer before you post. Try searching on this site, and in a search engine like Google.

There is also a Packaging & Deployment group on Drupal Groups

Many Drupal developers use Drush to deploy their content by syncing databases. Drush is included in Quickstart.

Many Drupal developers use Git for version control of code.

Also take a look at Comparison of staging and deployment modules

You can also benefit from deploying your live, test and remote dev environments in a Drupal-specific managed hosting environment such as those provided by Pantheon and Acquia.

It's not clear what you mean by

My live site has .htaccess but after running drush, this file is not present on my virtual machine.

- Drupal comes with an .htaccess file, and if it's missing you can copy it from your live site or a fresh Git clone or tarball of Drupal. It is necessary for things like "clean urls." Also, when discussing Drush, you should specify the command you used.

Finally, your question will likely be removed by administrators as misplaced. I am going to send this to you via the contact page on your account.