Difference between revisions of "Backups"
m (typos corrected, 3 - 2 - 1 added) |
|||
| (8 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
{{manual}} | {{manual}} | ||
| − | + | [[Category:Management]] | |
===Why Backup?=== | ===Why Backup?=== | ||
| − | It is almost certain that you will be storing valuable information in your Eprints server. Even assuming that the | + | 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=== | ===What to Backup=== | ||
You need to backup two things. | You need to backup two things. | ||
| − | The <tt>/opt/ | + | The <tt>/opt/eprints3/</tt> 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 (symbolic) linked directory too. |
Each MySQL database which your archives use. See the MySQL manual for more information on backing up MySQL databases. The <tt>mysqldump</tt> command will dump the whole of a database as a big list of SQL commands to re-create it. | Each MySQL database which your archives use. See the MySQL manual for more information on backing up MySQL databases. The <tt>mysqldump</tt> command will dump the whole of a database as a big list of SQL commands to re-create it. | ||
| Line 16: | Line 16: | ||
* Regularly backup your EPrints archive and database. | * Regularly backup your EPrints archive and database. | ||
| − | * Keep | + | * Keep multiple sets of backups following the rule '3 - 2 - 1', i.e. |
| + | ** keep 3 sets (1 original + 2 copies) | ||
| + | ** at least on 2 media, | ||
| + | ** but '''not''' in 1 place! | ||
| − | * Keep a recent backup physically | + | * Keep a recent backup physically separate from the archive - either in another room or ideally another site (s.a., e.g. 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. | * 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 | + | * Assume that you will be restoring to different hardware - the tape drive may be stolen or melted too, and you'll be unable 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. | * 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. | ||
| Line 28: | Line 31: | ||
If you can't do all of these, which is admittedly a lot of extra work, then do as many as you can. | 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... | + | Fortune favours the backed-up. It always seems to be the un-backed-up systems that have disk crashes. Life's like that ... |
Latest revision as of 12:41, 2 August 2019
| Manual Sections | ||
| ||
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 (symbolic) linked directory 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 multiple sets of backups following the rule '3 - 2 - 1', i.e.
- keep 3 sets (1 original + 2 copies)
- at least on 2 media,
- but not in 1 place!
- Keep a recent backup physically separate from the archive - either in another room or ideally another site (s.a., e.g. 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 unable 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 ...
