Difference between revisions of "Backups"
| Line 1: | Line 1: | ||
| − | |||
| − | |||
===Why Backup?=== | ===Why Backup?=== | ||
It is almost certain that you will be storing valuable information in your Eprints server. Even assuming that the eprints code is 100% bug free and that you will never delete 8000 records when you run the wrong script at 3am, you ''still'' need to back up! Drives and fans break. Computers get stolen. Server rooms get flooded (that happened to us!). Buildings burn down (we lost an EPrints server that way). | It is almost certain that you will be storing valuable information in your Eprints server. Even assuming that the eprints code is 100% bug free and that you will never delete 8000 records when you run the wrong script at 3am, you ''still'' need to back up! Drives and fans break. Computers get stolen. Server rooms get flooded (that happened to us!). Buildings burn down (we lost an EPrints server that way). | ||
Revision as of 15:44, 4 January 2007
Why Backup?
It is almost certain that you will be storing valuable information in your Eprints server. Even assuming that the eprints code is 100% bug free and that you will never delete 8000 records when you run the wrong script at 3am, you still need to back up! Drives and fans break. Computers get stolen. Server rooms get flooded (that happened to us!). Buildings burn down (we lost an EPrints server that way).
What to Backup
You need to backup two things.
The /opt/eprints3/ directory (or whatever you called it). Not all the subdirectories have to be backed up, but it is much easier to backup the whole thing. Make sure that you back up any symbolicly linked directories too.
Each MySQL database which your archives use. See the MySQL manual for more information on backing up MySQL databases. The mysqldump command will dump the whole of a database as a big list of SQL commands to re-create it.
Best Practice
We strongly recommend that you:
- Regularly backup your EPrints archive and database.
- Keep mulitple sets of backups.
- Keep a recent backup physically sepearate from the archive - either in another room or ideally another site (ie. take it home).
- Regularly check that you can actually restore from your backup. It's not uncommon for people to produce a daily backup for years without checking it. When they come to need it, they discover that something has gone wrong and the backup is useless.
- Assume that you will be restoring to different hardware - the tape drive may be stolen or melted too, and you'll be unabled to get one just the same because they stopped making them! Check that your backups work on hardware other than that used to create them.
- Decide who is responsible for backups. Their responsibilities should include making sure that the above policies are implemented even if they are ill or unavailable and making sure that someone else knows how to take over making and restoring the backups if they leave or are hit by a bus.
If you can't do all of these, which is admittedly a lot of extra work, then do as many as you can.
Fortune favours the backed-up. It always seems to be the un-backed-up systems that have disk crashes. Life's like that...
