Backups And Restoring - Koha ey50

1. Backups and Restoring Chapter 7. Routine Maintenance

1. Backups and Restoring This section is a copy of a separate document by Joshua Ferraro, <jmf at kados dor org>, written 2004-12-13 and available at http://www.kohadocs.org/Backups_and_Restoring.html.

1.1. Introduction Understanding how to properly backup and restore your Koha installation is a critical step in istering Koha successfully. Not only are these skills needed in an emergency, such as a hard drive failure on your primary production machine, but they are also useful for when you update, upgrade, or anytime you plan to custom modify either the filesystem or the database. There are three main components of Koha that must be considered when backing up and restoring: the database, the Koha filesystem, and the operating system customizations for the system. This document describes every step necessary for backing up and restoring both the database and the filesystem and points out some important considerations when backing up the operating system customizations -- these customizations often vary widely from system to system.

1.2. Backing up and Restoring the Koha Database 1.2.1. Backups There are many ways to backup MySQL databases, or parts of databases. After reading this section I highly recommend reading the MySQL manual sections that discuss backing up and restoring data. You can find them online at http://dev.mysql.com/doc/mysql/en/index.html. Perhaps the best way to backup your Koha database manually is the mysqldump application. To backup the whole database you can invoke it thusly: [root@frodo]# mysqldump --add-drop-table -uroot pyour Koha > 2004_11_30_koha.sql Notice that this naming convention uses the date, which makes it easy to organize a number of backups in a directory without being confused about which backup corresponds to which date. It's also clear that it's an SQL backup. Choose your naming conventions wisely and you'll thank yourself when you run into trouble. Also notice the --add-drop-table option. This specifies that when you restore the data you will not append the data to existing data; additionally, if tables in your backup do not exist in the database they will be created.

If you plan to work on a specific table and you'd like to back up just that table you can use mysqldump to do that as well. Suppose you're working on the issues table. You can back it up thusly: [root@frodo]# mysqldump --add-drop-table -uroot pyour Koha.issues > 2004_11_30_koha.issues.sql For more information on backups using the mysqldump utility please see the MySQL manual section 8.8: The mysqldump Database Backup Program. For more ways to backup your database, the MySQL manual is your best reference. Now you can use the gzip program to compress the sql file and reduce it's overall size for easier transport: [root@frodo]# gzip 2004_11_30_koha.sql 1.2.2. Restoration To unzip your file (in case you need to restore your database) you simply type: [root@frodo]# gzip -d filename.tgz An sql file can be used to restore data using the MySQL command-line tool. Here's an example of how to restore the Koha database using an sql file called koha.sql: [root@frodo]# mysql -uroot -pyour Koha < koha.sql To restore a single table such as issues from a file called koha.issues.sql you would type: [root@frodo]# mysql -uroot -pyour Koha.issues < koha.issues.sql 1.2.3. Role of Replication as Backup In addition to being useful in load balancing, replication can serve as a realtime backup for your Koha system. You will need to manually promote a slave to serve as master, and you will likely need to adjust your local configurations depending on how you have your systems setup, but having replication in place will probably ensure the fastest route to recovery from a complete system crash. See the replication section of the MySQL manual for more details.

1.3. Backing up the Koha Filesystem Even if you don't plan to use the latest CVS updates for your installation, it might be worth your time to centralize your Koha installation filesystem to ease the backup and restore process. For more info on how to achieve that see the Updating Koha section of the Koha documentation.

To backup the Koha installation directory tree you need to ensure that all your Koha files are being considered. Most of them are located by default in /usr/local/koha. The koha-httpd.conf and the koha.conf files are located in the /etc/ directory. 1.3.1. Automating the Filesystem Backup Here's a short Perl script that I run with cron every evening. It backs up the filesystem using tar and gzip. You'll need to change some of the Configurable Variables for the script to work in your environment. Other than that, it's pretty much ready to go -- setup cron to run it nightly. #!/usr/bin/perl -w #This script assumes that you have set up a CVS repository #that is symlinked to your installation directories. For #info on setting that up see the Koha manual "Updating Koha" #Configurable Variables my $koha_base = "/build/websites/openils.com/koha"; #location of Koha cvs repo my $bak_loc = "/build/backups"; #where to put backups my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time); $year += "1900"; my $date = "$year-$mon-$mday"; #Backup the filesystem print "Backing up the filesystem\n"; print "Please wait ..."; `rm -rf $koha_base.bak`; #remove the previous backup ` $koha_base $koha_base.bak`; #make a new backup `tar -cvzf $bak_loc/$date-kohafilesystem.tgz $koha_base.bak`; #targzip it

1.4. Backing up the Local Operating System Configuration It's best to write a script to perform all the local operating system configurations as you would manually perform them to ensure that in the event of an emergency, you can simply run the script to set everything the way you had it before. The list of possible custom configuration files for your system is unlimited, so I can just list a few common examples that you might want to consider including as part of your regular backup scheme: httpd.conf my.cnf

any custom cron jobs related to Koha

1.5. Storing your Backup Offsite Using s You may want to keep a copy of your database, filesystem and operating system customizations on your production server to ease the process of restoring should the need arise. However, what if your hard drive on that machine crashes? It's a very good idea to store your backups on a different machine (or two or three) and it's probably a good ideal to store them in a different building too.

Perhaps the best way to avoid the problems inherent in physical backup medium such as a tape (that you may never really be sure is going to work anyway) is to use ssh and in particular s as a part of your backup process. Why mess with tapes when you can securely copy a file from one system to another? You can invoke s thusly: [root@frodo]# s koha.bak [email protected]:/build/backups/ The : signifies that this is a network address and also allows a specific directory to be specified on the receiving machine -- in this case, sam.openils.com has a /build/backups directory where I store backups.