Many Aegir users ask whether there is a way to schedule backups of all sites provisioned in Aegir. Currently at the time of writing, no such scheduling exists within Aegir itself, since we have a few design decisions to work out (such as where to store the backups, especially when multi-server comes in!)
For the meantime, here's a crude little shell script that might help you. You should execute it as the aegir user.
Users of Ubuntu with /bin/sh symlinked to /bin/dash might experience problems with Drush that have been documented elsewhere. Consider changing the shebang to #!/bin/bash and executing it with bash rather than sh.
Users that have Drush 2.1 or earlier and Aegir 0.4alpha3 or earlier should use the aegir_backup_0.4-alpha3.sh script. Users of Drush and Aegir HEAD components, or anything higher than Drush 2.1, should use the aegir_backup.sh script. The difference is that the backup command (like all other of our Drush commands) has changed in Aegir from 'provision backup' to 'provision-backup', to make Aegir compatible with the next version of Drush which uses hyphenated commands.
The latest versions of the scripts are always available on git.mig5.net in the scripts repository.
Hopefully you don't need to change any variables if you are using the recommended file structure (/var/aegir/config/vhost.d to store the apache vhost configs etc), but you can if you wish, and you can tweak the verbosity.
Please do test and let me know if it works. It works for me. Ideally you'd put it in aegir's crontab to run hourly or daily or somesuch, i.e midnight every night:
0 0 * * * bash /var/aegir/aegir_backup.sh
Note that because these provision-backup scripts are being executed only from the backend via the CLI and not via the Hosting frontend, they aren't associated with the Aegir database/task store in any way, meaning that these backups aren't registered in Aegir as being available to use the Restore command against (at least, not through the frontend). You would have to restore from these backups manually with the 'provision-restore' or provision-deploy command, which is unfortunate, but hey! at least you have backups right? :)
This whole process will get a lot easier if/when we get scheduled backups implemented properly. I hope this helps you.
It works!
Great, thanks for this, perfect timing as I've spent the last few days sorting out all my backup procedures - no more sleepless nights, thanks ;)
hmmm - actually
The backups work and get stored in the /aegir/backups directory but I am unable to see them in the GUI under the restore tab. Is the normal?
Hi Matt, Yes, you won't see
Hi Matt,
Yes, you won't see them in the Restore tab. Per the last paragraph in the article:
Backups are seen in the Restore tab because the backup information is stored in the Aegir database itself when a Backup is run from the web interface. When a backup is run from the commandline, there is no way it can be associated with the site node in the frontend, so the 'link' is not there.
Awesome!
I was wondering how to do this myself. Can't wait for scheduled backups to be front-end friendly. :-)
drush multiple server feature
drush head just got the feature to run same command on multiple site aliases with a single invocation. see http://drupal.org/node/628996. so your loop is no longer needed. we ought to think about how aegir is gonna use the new sitealias features.
Thanks Moshe. Yes this
Thanks Moshe. Yes this current implementation was very much limited to a single server since the check is rather crude and being done on Apache vhost configs on the local system. It probably should (at least) check from hosting_site on the aegir node, when multiserver comes in.
And in this case it is ignoring site aliases since we don't want to run a backup for multiple aliases of the same site/database
It could also be interesting to group selections of sites into 'development' and 'live' groups per that ticket, though in my case I'd probably be logically separating such relationships by server entirely.. but that's offtopic. And I need to properly digest everything in that ticket first :)
¡ɹǝpunuʍop ǝʌıן ı
¡ɹǝpunuʍop ǝʌıן ı
Dad, that looks like Russian
Dad, that looks like Russian spam. WTF!
Post new comment