To back up your Evergreen system, you have to consider three major categories of volatile data:

1. Data stored in Evergreen's database
2. Customizations to Evergreen (themes, skins, configuration files, staff client)
3. The operating system itself

You should follow the principles of good system administration and ensure that you store your backups on separate machines (ideally with some backups stored offsite), regularly check your backup and restore procedures, ensure that the backups are only accessible by authorized personnel, etc. Such a discussion is beyond the scope of this documentation; we recommend you consult one of the core system administration books to learn more about the principles of system administration with respect to backups.

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 as follows:

# pg_dump -U <username> -h <hostname> -f <output-file> <database-name> 
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, set the locale to "C" and the encoding as UNICODE, then run the pg_restore command, specifying the new database as your target. Replace "x.x" with your version of PostgreSQL:

createdb -T template0 --lc-ctype=C --lc-collate=C -E UNICODE evergreen
createlang plperl   evergreen
createlang plperlu  evergreen
createlang plpgsql  evergreen
psql -f /usr/share/postgresql/x.x/contrib/tablefunc.sql evergreen
psql -f /usr/share/postgresql/x.x/contrib/tsearch2.sql  evergreen
psql -f /usr/share/postgresql/x.x/contrib/pgxml.sql     evergreen
 
# pg_restore -U evergreen -h localhost -d <db_name> -v "<backup_file_name>" -W
pg_restore -U evergreen -h localhost -d evergreen -v evergreen_db.backup -W

Note that if using PostgreSQL 8.4 or newer, it is recommend that you use the option -j=X for parallel loads where X is the number of parallel processes.

Also 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.

When you deploy Evergreen, you have to customize a number of files: from setting authentication information in opensrf_core.xml and opensrf.xml to defining overdue notice templates and circulation rules. You will also create at least one custom skin and theme for your catalogue, and may create a custom staff client. As well, you will also customize Apache and ejabberd configuration files to match the needs of your system.

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, Subversion, or CVS 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.

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.