bin/backup script: sensible defaults around bin/repozo
bin/repoze is a zope script to make backups of your Data.fs. Looking up the settings can be a chore. And you have to pick a directory where to put the backups. This recipe provides sensible defaults for your common backup tasks. Making backups a piece of cake is important!
- bin/backup makes a backup.
- bin/restore restores the latest backup.
- bin/snapshotbackup makes a full backup, separate from the regular backups. Handy for copying the current production database to your laptop or right before a big chance in the site.
Some extra information:
- Code repository: https://svn.plone.org/svn/collective/buildout/collective.recipe.backup
- Questions and comments to mailto:firstname.lastname@example.org
The simplest way to use it to add a part in buildout.cfg like this:
>>> write('buildout.cfg', ... """ ... [buildout] ... parts = backup ... ... [backup] ... recipe = collective.recipe.backup ... """)
Running the buildout adds a backup, snapshotbackup and restore scripts to the bin/ directory and, by default, it creates the var/backups and var/snapshotbackups dirs:
>>> print system(buildout) # doctest:+ELLIPSIS Installing backup. backup: Created /sample-buildout/var/backups backup: Created /sample-buildout/var/snapshotbackups Getting distribution for 'zc.recipe.egg'. Got zc.recipe.egg 1.0.0. Generated script '/sample-buildout/bin/backup'. Generated script '/sample-buildout/bin/snapshotbackup'. Generated script '/sample-buildout/bin/restore'. <BLANKLINE> >>> ls('var') d backups d snapshotbackups >>> ls('bin') - backup - buildout - restore - snapshotbackup
Calling bin/backup results in a normal repozo backup. We put in place a mock repozo script that prints the options it is passed (and make it executable). It is horridly unix-specific at the moment.
>>> import sys >>> write('bin', 'repozo', ... "#!%s\nimport sys\nprint ' '.join(sys.argv[1:])" % sys.executable) >>> #write('bin', 'repozo', "#!/bin/sh\necho $*") >>> dontcare = system('chmod u+x bin/repozo')
By default, backups are done in var/backups:
>>> print system('bin/backup') --backup -f /sample-buildout/var/filestorage/Data.fs -r /sample-buildout/var/backups INFO: Backing up database file: ...
You can restore the very latest backup with bin/restore:
>>> print system('bin/restore') --recover -o /sample-buildout/var/filestorage/Data.fs -r /sample-buildout/var/backups INFO: Restoring...
You can also restore the backup as of a certain date. Just pass a date argument. According to repozo: specify UTC (not local) time. The format is yyyy-mm-dd[-hh[-mm[-ss]]].
>>> print system('bin/restore 1972-12-25') --recover -o /sample-buildout/var/filestorage/Data.fs -r /sample-buildout/var/backups -D 1972-12-25 INFO: Date restriction: restoring state at 1972-12-25. INFO: Restoring...
For quickly grabbing the current state of a production database so you can download it to your development laptop, you want a full backup. But you shouldn’t interfere with the regular backup regime. Likewise, a quick backup just before updating the production server is a good idea. For that, the bin/snapshotbackup is great. It places a full backup in, by default, var/snapshotbackups.
>>> print system('bin/snapshotbackup') --backup -f /sample-buildout/var/filestorage/Data.fs -r /sample-buildout/var/snapshotbackups -F INFO: Making snapshot backup:...
The recipe supports the following options, none of which are needed by default. The most common one to change is location, as that allows you to place your backups in some system-wide directory like /var/zopebackups/instancename/.
- Location where backups are stored. Defaults to var/backups inside the buildout directory.
- Number of full backups to keep. Defaults to 0, which means old backups are not removed. 2, for instance, means that the current and the previous full backup are kept. Older backups are removed, including their incremental backups.
- In case the Data.fs isn’t in the default var/filestorage/Data.fs location, this option can overwrite it.
- By default, incremental backups are made. If this option is set to ‘true’, bin/backup will always make a full backup.
- In rare cases when you want to know exactly what’s going on, set debug to ‘true’ to get debug level logging.
- Location where snapshot defaults are stored. Defaults to var/snapshotbackups inside the buildout directory.
We’ll use the three options.
>>> write('buildout.cfg', ... """ ... [buildout] ... parts = backup ... ... [backup] ... recipe = collective.recipe.backup ... location = /backups/myproject ... keep = 3 ... datafs = subfolder/myproject.fs ... full = true ... debug = true ... snapshotlocation = snap/my ... """) >>> print system(buildout) # doctest:+ELLIPSIS Uninstalling backup. Installing backup. backup: Created /sample-buildout/snap/my Generated script '/sample-buildout/bin/backup'. Generated script '/sample-buildout/bin/snapshotbackup'. Generated script '/sample-buildout/bin/restore'. <BLANKLINE>
Backups are now stored in /backups/myproject and the Data.fs location is handled correctly despite being a relative link:
>>> print system('bin/backup') --backup -f /sample-buildout/subfolder/myproject.fs -r /backups/myproject -F INFO: Backing up database file: ...
The same is true for the snapshot backup.
>>> print system('bin/snapshotbackup') --backup -f /sample-buildout/subfolder/myproject.fs -r /sample-buildout/snap/my -F INFO: Making snapshot backup:...
collective.recipe.backup is basically a port of ye olde instancemanager’s backup functionality. That backup functionality was coded mostly by Reinout van Rees and Maurits van Rees, both from Zest software
Creating the buildout recipe was done by Reinout.
- Added bin/restore. [reinout]
- Added snapshot backups. [reinout]
- Enabled cleaning up of older backups. [reinout]
- First working version that runs repozo and that creates a backup dir if needed. [reinout]
- Started project based on zopeskel template. [reinout]