 |   | |
| HomePrev | Part VIII. Backing up your Evergreen System | Next |
|---|
Table of Contents
Although it might seem pessimistic, spending some of your limited time preparing for disaster is one of the best investments you can make for the long-term health of your Evergreen system. If one of your servers crashes and burns, you want to be confident that you can get a working system back in place — whether it is your database server that suffers, or an Evergreen application server.
At a minimum, you need to be able to recover your system’s data from your PostgreSQL database server: patron information, circulation transactions, bibliographic records, and the like. If all else fails, you can at least restore that data to a stock Evergreen system to enable your staff and patrons to find and circulate materials while you work on restoring your local customizations such as branding, colors, or additional functionality. This section describes how to back up your data so that you or a colleague can help you recover from various disaster scenarios.
The simplest method to back up your PostgreSQL data is to use the pg_dump utility to create a logical
backup of your database. Logical backups have the advantage of taking up minimal space, as the indexes
derived from the data are not part of the backup. For example, an Evergreen database with 2.25 million
records and 3 years of transactions that takes over 120 GB on disk creates just a 7.0 GB compressed
backup file. The drawback to this method is that you can only recover the data at the exact point in time
at which the backup began; any updates, additions, or deletions of your data since the backup began will
not be captured. In addition, when you restore a logical backup, the database server has to recreate all
of the indexes—so it can take several hours to restore a logical backup of that 2.25 million record
Evergreen database.
As the effort and server space required for logical database backups are minimal, your first step towards preparing for disaster should be to automate regular logical database backups. You should also ensure that the backups are stored in a different physical location, so that if a flood or other disaster strikes your primary server room, you will not lose your logical backup at the same time.
To create a logical dump of your PostgreSQL database:
pg_dump -Fc <database-name> > <backup-filename>. If you
are not running the command as the postgres user on the database server itself, you may need to include
options such as -U <user-name> and -h <hostname> to connect to the database server. You can use a
newer version of the PostgreSQL to run pg_dump against an older version of PostgreSQL if your client
and server operating systems differ. The -Fc option specifies the "custom" format: a compressed format
that gives you a great deal of flexibility at restore time (for example, restoring only one table from
the database instead of the entire schema).
You should establish a routine of nightly logical backups of your database, with older logical backups being automatically deleted after a given interval.
To report a problem with this documentation or provide feedback, please contact the DIG mailing list.
© 2008-2015 GPLS and others. The Evergreen Project is a member of the Software Freedom Conservancy.
