Backing Up

Backing up your system files and data is a critical task for server and database administrators. Having a strategy for backing up and recovery could be the difference between a minor annoyance for users and a complete catastrophe.

Backing up the Evergreen Database

Most of the critical data for an Evergreen system – patrons, bibliographic records, holdings, transactions, bills – is stored in the PostgreSQL database. You can therefore use normal PostgreSQL backup procedures to backup this data. For example, the simplest method of backing up the Evergreen database is to use the pg_dump command to create a live backup of the database without having to interrupt any Evergreen services. Here is an example pg_dump command which will dump a local Evergreen database into a the file evergreen_db.backup:

pg_dump -U evergreen -h localhost -f evergreen_db.backup evergreen

To restore the backed up database into a new database, create a new database using the template0 database template and the UTF8 encoding, and run the psql command, specifying the new database as your target:

createdb -T template0 -E UTF8 -U evergreen -h localhost new_evergreen
psql -U evergreen -h localhost -f evergreen_db.backup new_evergreen


This method of backup is only suitable for small Evergreen instances. Larger sites should consider implementing continuous archiving (also known as log shipping) to provide more granular backups with lower system overhead. More information on backing up PostgreSQL databases can be found in the official PostgreSQL documentation.

Backing up Evergreen Files

When you deploy Evergreen, you will probably customize many aspects of your system including the system configuration files, Apache configuration files, OPAC and Staff Client. In order to protect your investment of time, you should carefully consider the best approach to backing up files.

There are a number of ways of tackling this problem. You could create a script that regularly creates a time-stamped tarball of all of these files and copies it to a remote server - but that would build up over time to hundreds of files. You could use rsync to ensure that the files of interest are regularly updated on a remote server - but then you would lose track of the changes to the files, should you make a change that introduces a problem down the road.

Perhaps one of the best options is to use a version control system like Bazaar, git or Subversion to regularly push updates of the files you care about to a repository on a remote server. This gives you the advantage of quickly being able to run through the history of the changes you made, with a commenting system that reminds you why each change was made, combined with remote storage of the pertinent files in case of disaster on site. In addition, your team can create local copies of the repository and test their own changes in isolation from the production system. Using a version control system also helps to recover system customizations after an upgrade.

Full System Backup

A full system backup archives every file on the file system. Some basic methods require you to shut down most system processes; other methods can use mirrored RAID setups or SAN storage to take snapshot backups of your full system while the system continues to run. The subject of how to implement full system backups is beyond the scope of this documentation.