Document Actions
Backup Plone
This How-to applies to:
Any version.
This How-to is intended for:
Server Administrators
What to backup?
You should backup at least:
- Your content. This usually resides in the Zope database file Data.fs in the var directory of your Zope instance.
- Customizations you may have made on the file system.
- All products that are installed. These are required to restore your site in a fresh Plone installation. Backup the entire Products directory of your Zope instance, as well as any directories where symbolic links in Products may be pointing to. You don't necessarily need to backup products that you can restore from archives on the Internet (such as Plone's SVN). However, when you need to restore from backup, you'll require the same versions of the products that are used in your websites on the backup. Backing up the products is fail-safe and does not depend on external archives.
- External methods in the Extensions directory of your Zope instance.
- Your Zope configuration file (usually zope.conf in the etc directory of your Zope instance).
- Your custom translation files (usually in the i18n directory of your Zope instance).
Most of these files can simply be copied to a backup server or medium (for example, by means of a daily rsync of your zope instance). The database file Data.fs is an exception to this rule, however.
How to backup your content in the database file Data.fs
You should take special care when copying Data.fs, since this file can be modified when Plone is up and running during the backup operation. Although Plone (Zope actually) can usually recover the database file in that situation, there are some exceptions to this rule (such as when an undo or pack operation is in progress during the backup). We strongly recommend, therefore, that you backup Data.fs in one of the following ways.
- Use Repozo
- The recommended way to backup the database is to use Zope's
repozo.pyscript. In this way you can perform a safe and automated backup while Plone is running, without side-effects on your data. It's generally considered the best practice for backing up Zope/Plone in a production environment.Repozo can be used to create a full backup of the database. Since Plone stores its data in a single large binary file, creating a daily full backup may consume too much storage and network resources. In that case, you can also use Repozo to create an incremental hot backup of the database.
More information about Repozo can be found in Backing up FileStorage files on Zope's website. The
repozo.pyscript can be found in the bin directory of your Zope software installation. It contains an informative docstring about its command line options. - Shutdown Zope and backup the database
- The easiest way to safely backup the database is to stop (shutdown) Zope, copy Data.fs and restart Zope. This is simple and safe, but has the disadvantage that your sites are down for some time.
- Pack the database and backup the pre-pack copy
- Another way to safely backup Data.fs without bringing down your sites, is to pack the database in the Zope management interface (ZMI): Control panel > Database management > Main > Pack. This leaves a file Data.fs.old with the previous contents of the database. Since Plone does not write to that file anymore after packing, it's safe to backup this file after packing while Plone remains running. Be sure to backup Data.fs.old and not just Data.fs.
Packing the database means reducing its size by deleting archived versions of stored objects, older than a specified age. After packing, you'll no longer be able to revert to these old versions by undoing transactions.
A product that may come in handy is PloneMaintenance. You can use this to automatically pack the database from time to time. You can configure it, for example, to pack the database every night before the system backup script runs on your server. In this way, you'll get a safe daily backup of the database (assuming the system backup is guaranteed to run after the database has been packed).
Re: rsync / FileStorage
1. I cron repozo to run daily (originally 4 times a day, but that was overkill).
2. From my backup server (on which I've already created and configured the Zope environment) I rsync the Products directory (removing deleted files), the repozo directory (keeping deleted files) and the Apache vhost files (deleting the removed files).
In the event of catastrophe (or a user deleted something 2 weeks ago and just noticed today):
1. Build the ZODB from repozo.
2. Fire up Zope.
3. Make any changes necessary to route the traffic to the new server or export the deleted content to restore on the main server.
I have used this process multiple times, including one instance where an entire VM's SAN disk space was removed and has proven to be very effective. Turn around time of less than 15 minutes for a 2-5Gb site.
Re: rsync / FileStorage
1. I cron repozo to run daily (originally 4 times a day, but that was overkill).
2. From my backup server (on which I've already created and configured the Zope environment) I rsync the Products directory (removing deleted files), the repozo directory (keeping deleted files) and the Apache vhost files (deleting the removed files).
In the event of catastrophe (or a user deleted something 2 weeks ago and just noticed today):
1. Build the ZODB from repozo.
2. Fire up Zope.
3. Make any changes necessary to route the traffic to the new server or export the deleted content to restore on the main server.
I have used this process multiple times, including one instance where an entire VM's SAN disk space was removed and has proven to be very effective. Turn around time of less than 15 minutes for a 2-5Gb site.
zeopack.py
env PYTHONPATH=/usr/lib/zope2.9/lib/python /usr/lib/zope2.9/bin/zeopack.py -p 8100 -d 7
scripts for backup and recover
http://plone.org/documentation/how-to/backup-and-recover-data-fs-in-linux
This doesn't use rsync, but the more traditional approach of taking daily (or more frequent) backups so that you have versions (not to say you can't in turn do that from the rsync destination).
rsync / FileStorage
- FileStorage (not in the mode of packing) appends all changes to the database file (default name is Data.fs). This means if you copy it while its mid write; you would only lose that transaction. This is not as critical as it sounds (at least not in the systems Enfold builds). Also the HUGE upside of FileStorage is that you can easily track down 'bad' ransactions and truncate the database at that points. Restart zope and voila -- you are back at the state you were before the 'bad' tranaction. An example of a 'bad' tranasaction was recently we had a sysadmin run 'reinstall' for a 3rd party addon which destroyed how views were being calculated (really strange 3rd party product)
- BSDDBStorage, as with any berkelydb you need to be very very careful about backing up.
- DirectoyrStrorage should have no problems just being backed up. It should be very resilient.
- RDBMStorage's should be able to back per RDBMS vendor instructions.
Lots of options. The best 'warm backup' situation is Filestorage + repozo + rsync (if I understand correctly). I'm not involved in configuring this stuff. But I know rsync has helped tremendously.