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

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.

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.