Backups - Revision history

Th.lauke@arcor.de: typos corrected, 3 - 2 - 1 added

2019-08-02T12:41:16Z

typos corrected, 3 - 2 - 1 added

Drn@ecs.soton.ac.uk at 12:50, 8 September 2017

2017-09-08T12:50:29Z

Drn@ecs.soton.ac.uk at 16:01, 6 September 2017

2017-09-06T16:01:12Z

Pm705 at 11:28, 8 February 2010

2010-02-08T11:28:49Z

WikiSysop at 15:44, 4 January 2007

2007-01-04T15:44:26Z

WikiSysop at 15:44, 4 January 2007

2007-01-04T15:44:19Z

WikiSysop at 15:44, 4 January 2007

2007-01-04T15:44:16Z

Moj at 12:15, 3 January 2007

2007-01-03T12:15:20Z

WikiSysop at 17:45, 1 March 2006

2006-03-01T17:45:38Z

WikiSysop at 17:45, 1 March 2006

2006-03-01T17:45:32Z

@@ Line 2: / Line 2: @@
 [[Category:Management]]
 ===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).
 ===What to Backup===
 You need to backup two things.
-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 symbolicly linked directories too.
+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.
@@ Line 16: / Line 16: @@
 * Regularly backup your EPrints archive and database.
-* Keep mulitple sets of backups.
+* Keep multiple sets of backups following the rule '3 - 2 - 1', i.e.
-* Keep a recent backup physically sepearate from the archive - either in another room or ideally another site (ie. take it home).
+* 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 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.
+* 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.
@@ 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.
-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 ...

← Older revision		Revision as of 12:50, 8 September 2017
Line 1:		Line 1:
		+	{{manual}}
	[[Category:Management]]		[[Category:Management]]
	===Why Backup?===		===Why Backup?===

@@ Line 1: / Line 1: @@
 [[Category:Management]]
 ===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).

← Older revision		Revision as of 11:28, 8 February 2010
Line 1:		Line 1:
		+	[[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 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).

← Older revision		Revision as of 15:44, 4 January 2007
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).

← Older revision		Revision as of 12:15, 3 January 2007
Line 1:		Line 1:
		+	{{development}}
	{{manual}}		{{manual}}

@@ Line 1: / Line 1: @@
 {{manual}}
-{{Category:Manual}}
 ===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!). Without proper backups this could be a disaster.