Using Drupal with Amazon S3 to backup your site
Thu, 07/15/2010 - 7:17pm
I would like to share with you an extremely inexpensive and highly effective way to backup your Drupal sites (both MySQL and your /sites/default/files directory)
You will need two things;
One is this module: http://drupal.org/project/backup_migrate
Second, you will need an Amazon S3 Account >here
How does it work? very simple, you create a Bucket (folder) in Amazon S3
and then go into the Backup and Migrate module and enter your settings.
You can backup just the db or just the files directory or both. One of the best features is the ability to restore a backed up MySQL file, the module actually lists the backed up files, select the one you want to back up and it magically restores the db to the state of when the back up was done. This one has saved me a few times!
The cost? Well, I back up three sites, with one site having doing a 150MB four times per day is costing me $2.58 per month.
Oh, and that 150MB backup takes about 35 seconds!!
Tue, 03/08/2011 - 1:57am
#2
Backup Client-Server
You can also do this automatically by using this module: Backup Client-Server ( http://drupal.org/project/backup_client_server ).
It allows for backup of multiple databases, website files, scheduled backups, push them to Amazon S3, automatically delete backups ... and a few other various configurations.
Check it out, took me 10 minutes to set up.
Fri, 05/20/2011 - 3:56pm
#3
There are caveats to mention!
@JoaoMachado, this is definitely good stuff! But there are some caveats.
backup_migrate stores your Amazon Web Services key/secret key in plain text in the Drupal database. So it is a pretty insecure proposition to be doing things the way you describe, though certainly efficient. And given how many people simply backup their Drupal dbs on their local box, an improvement.
But you can mitigate the security problem in the following way. Now that Amazon Web Services (AWS) have "Identity management" available via a GUI, things have gotten much easier for less-than-uber-geeks to take advantage of AWS power. You should create a user specifically for backup_migrate.
And here is the (less than uber) geeky part... you add the following "policy" under the permission tab for the "user". This is your AWS user, not in Drupal at all. Here is policy to use (note: the code below is not PHP or Drupal, it is AWS policy language, meant to be used inside your AWS account):
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:ListBucketVersions"
],
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl",
"s3:PutObjectAclVersion"
],
"Resource": "arn:aws:s3:::*"
}
]
}This permission only allows the user accessing AWS via backup_migrate to write files to your Amazon S3 space.
So even if the user key/secret-key which are written in plane text in the Drupal DB were compromised, the only thing the intruder would be able to do is write files to your S3 space... which is not really a dangerous thing.
Note that the policy as written above will not allow backup_migrate to delete files from S3 so that the backup_migrate functionality that automatically deletes files based on the number of files you set for a particular destination, will not work.
Also, when you "list files" within backup_migrate, you won't be able to download or restore copies of the db. I find the fact that this approach (using AWS identity management fine-grained policy permissions) disables those features is simply another security advantage. To restore, you just go to S3, download to your desktop and then use backup_migrate to restore from your desktop.
But in short, it is NOT a best practice to put your master AWS key/secret_key into a Drupal database. It's just asking for trouble.
I'll try to post back after I've written this up as a Drupal doc which I intend to do.
Launching AWS power has really been a super geeky thing to do, but as a non-super geek, I must say they are making things easier... and the GUI for identity management is HUGE.
Thanks for the post.
Not bad! I take a little different approach, since I have a nice hosting account with SSH, root access, etc...
I use a cron rsync script that synchronizes my site data every hour with a local backup, then, on top of that, I use Drush to synchronize the production site database with my local computer every hour. It's a good alternative, if you can have a computer running 24x7 locally...
Advancing the faith.