Proposed changes to backup and archiving - Revision history

import>Cen1001: /* New backup system */

2006-06-29T11:03:56Z

New backup system

← Older revision		Revision as of 11:03, 29 June 2006
Line 10:		Line 10:
	==New backup system==		==New backup system==

	I want to buy a new backup server with ~~at least~~ 6Tb of space, move the		I want to buy a new backup server with about 6Tb of space, move the
	backups onto that, and make them user-accessible. We would have to keep		backups onto that, and make them user-accessible. We would have to keep
	one of the old backup servers running for technical reasons: some of the		one of the old backup servers running for technical reasons: some of the
Line 21:		Line 21:
	the default is to have world-readable files, and people forget to change them. If we think this will cause problems then we would have to change the default.		the default is to have world-readable files, and people forget to change them. If we think this will cause problems then we would have to change the default.

			The cost of such a new server would be a maximum of 7500ukp (inc VAT), which is the cost of an Apple xServe RAID with 6Tb. In practice we'd buy a PC-based whitebox machine which should be cheaper. I would guess a maximum of 6000ukp but have not got firm figures as these can't be bought off the shelf. If that is too high we could buy a smaller system with expansion room, but expansion is likely to be very disruptive.
	The cost of such a new server would be XXX

	==New archive system==		==New archive system==

import>Cen1001: /* Background */

2006-06-29T10:58:32Z

Background

← Older revision		Revision as of 10:58, 29 June 2006
Line 1:		Line 1:
	==~~Background~~==		==Current systems==

	We need more backup space as workstation disks are getting larger and we		We need more backup space as workstation disks are getting larger and we

import>Cen1001: /* Background */

2006-06-29T10:58:13Z

Background

← Older revision		Revision as of 10:58, 29 June 2006
Line 6:		Line 6:
	restores; it would be an improvement if people could access their own backups. It would also be very useful to be able to keep some backups for longer than the current two weeks.		restores; it would be an improvement if people could access their own backups. It would also be very useful to be able to keep some backups for longer than the current two weeks.

	Our existing archive server is not user accessible. It is ~~difficult to use,~~ unreliable, and has no free space.		Our existing archive server is not user accessible. It is unreliable, and has no free space.

	==New backup system==		==New backup system==

import>Cen1001: /* New archive system */

2006-06-29T10:57:43Z

New archive system

← Older revision		Revision as of 10:57, 29 June 2006
Line 26:		Line 26:

	The other two old backup servers would immediately be free for reuse. I		The other two old backup servers would immediately be free for reuse. I
	would make those into an ~~improved and higher capacity~~ archive system. This		would make those into a new archive system. This would let us clear old homespaces off clusters and workstations as soon as people leave while
		⚫	keeping a read-only copy available. Assuming people set their file permissions appropriately on the original data, the rest of their research group will be able to access it on the archive server. The same issue with world-readable files arises as with the backup server.
	would let us clear old homespaces off clusters and workstations while
⚫	keeping a read-only copy available ~~to users~~. Assuming people set their file permissions appropriately on the original data, the rest of their research group will be able to access it on the archive server. The same issue with world-readable files arises.

			The data would be read only so we don't need regular backups of it: the two servers would each contain a copy and be sited a long way apart. Software would regularly check to see if the copies were identical in order to pick up any problems.
	The data won't change so we don't need
	regular backups of it: the two servers would be set up to mirror each other and be
	sited a long way apart.

	There will have to be some sort of time limit on how long we keep the		There will have to be some sort of time limit on how long we keep the
	archive data otherwise we will just run out of space again. This might vary from account to account. ~~One~~ ~~way~~ to do		archive data otherwise we will just run out of space again. This might vary from account to account. When the date comes round the leader of the group would be told, and would have a chance to extend the date. I would rather leave it to the leader of the group than the owner of the data because, by the time the date comes round (I would imagine at least a year after the owner leaves) I will probably not have reliable contact details for them.
	it would be to have a 'deletion date' for each account which could be
	extended if needed. I could then warn the leader of the group who produced
	the data when the date came round, before actually deleting data. It is
	impossible for me to reliably warn the owner of the data because once
	they've left they don't tell me about changes in their contact details.

import>Cen1001: /* New backup system */

2006-06-29T09:55:20Z

New backup system

← Older revision		Revision as of 09:55, 29 June 2006
Line 18:		Line 18:

	There is one potential disadvantage to this proposal: having		There is one potential disadvantage to this proposal: having
	user-restorable backups means that files which are set to be 'world-readable' become readable by anyone in the entire sector, even if they don't have a user account on the machine the original file was on. Anyone who doesn't want this can protect themselves by changing their file permissions to no longer be world-readable. However ~~IME this is often a cause of problems because people forget to do it.~~		user-restorable backups means that files which are set to be 'world-readable' become readable by anyone in the entire sector, even if they don't have a user account on the machine the original file was on. Anyone who doesn't want this can protect themselves by changing their file permissions to no longer be world-readable. However
			the default is to have world-readable files, and people forget to change them. If we think this will cause problems then we would have to change the default.

	The cost of such a new server would be XXX		The cost of such a new server would be XXX

import>Cen1001: /* New backup system */

2006-06-29T09:54:01Z

New backup system

← Older revision		Revision as of 09:54, 29 June 2006
Line 18:		Line 18:

	There is one potential disadvantage to this proposal: having		There is one potential disadvantage to this proposal: having
	user-restorable backups means that files which are set to be 'world-readable' become readable by anyone in the entire sector, even if they don't have a user account on the machine the original file was on. Anyone who doesn't want this can protect themselves by changing their file permissions to no longer be world-readable. However IME ~~some people don't do~~ this ~~even~~ if ~~warned,~~ ~~and~~ ~~are~~ ~~then~~ ~~unpleasantly~~ ~~surprised~~ ~~when~~ ~~they~~ ~~discover others can read their~~ ~~files~~.		user-restorable backups means that files which are set to be 'world-readable' become readable by anyone in the entire sector, even if they don't have a user account on the machine the original file was on. Anyone who doesn't want this can protect themselves by changing their file permissions to no longer be world-readable. However IME this is often a cause of problems because people forget to do it.

	The cost of such a new server would be XXX		The cost of such a new server would be XXX

import>Cen1001: /* New backup system */

2006-06-29T09:52:37Z

New backup system

← Older revision		Revision as of 09:52, 29 June 2006
Line 18:		Line 18:

	There is one potential disadvantage to this proposal: having		There is one potential disadvantage to this proposal: having
	user-restorable backups means that files which are 'world-readable' ~~inUnix terms (ie~~ readable by anyone ~~with~~ an ~~account~~ on ~~the~~ ~~machine~~ they ~~are~~ ~~on)~~ ~~become~~ ~~readable~~ by ~~anyone~~ in the ~~entire~~ ~~sector~~. Anyone who doesn't want this can protect themselves by changing their file permissions to no		user-restorable backups means that files which are set to be 'world-readable' become readable by anyone in the entire sector, even if they don't have a user account on the machine the original file was on. Anyone who doesn't want this can protect themselves by changing their file permissions to no longer be world-readable. However IME some people don't do this even if warned, and are then unpleasantly surprised when they discover others can read their files.
	longer be world-readable, but IME people don't, even if warned, and are
	often unpleasantly surprised when they discover others can read their
	files.

			The cost of such a new server would be XXX

	==New archive system==		==New archive system==

import>Cen1001: /* New archive system */

2006-06-29T09:47:18Z

New archive system

← Older revision		Revision as of 09:47, 29 June 2006
Line 29:		Line 29:
	would make those into an improved and higher capacity archive system. This		would make those into an improved and higher capacity archive system. This
	would let us clear old homespaces off clusters and workstations while		would let us clear old homespaces off clusters and workstations while
			keeping a read-only copy available to users. Assuming people set their file permissions appropriately on the original data, the rest of their research group will be able to access it on the archive server. The same issue with world-readable files arises.
⚫	~~keeping a read-only copy available.~~ The data won't change so we don't need

⚫	regular backups of it: the two servers would mirror each other and be
		⚫	The data won't change so we don't need
		⚫	regular backups of it: the two servers would be set up to mirror each other and be
	sited a long way apart.		sited a long way apart.

	There will have to be some sort of time limit on how long we keep the		There will have to be some sort of time limit on how long we keep the
	archive data. ~~This~~ will might vary from account to account. One way to do		archive data otherwise we will just run out of space again. This might vary from account to account. One way to do
	it would be to have a 'deletion date' for each account which could be		it would be to have a 'deletion date' for each account which could be
	extended if needed. I ~~would~~ then warn the leader of the group who produced		extended if needed. I could then warn the leader of the group who produced
	the data when the date came round, before actually deleting ~~things~~. It is		the data when the date came round, before actually deleting data. It is
	impossible for me to reliably warn the owner of the data because once		impossible for me to reliably warn the owner of the data because once
	they've left they don't tell me about changes in their contact details.		they've left they don't tell me about changes in their contact details.

import>Cen1001: /* Background */

2006-06-29T09:43:51Z

Background

← Older revision		Revision as of 09:43, 29 June 2006
Line 6:		Line 6:
	restores; it would be an improvement if people could access their own backups. It would also be very useful to be able to keep some backups for longer than the current two weeks.		restores; it would be an improvement if people could access their own backups. It would also be very useful to be able to keep some backups for longer than the current two weeks.

	Our existing archive server is not user accessible, is difficult to use ~~and~~ unreliable, and is ~~completely~~ ~~full.~~		Our existing archive server is not user accessible. It is difficult to use, unreliable, and has no free space.

	==New backup system==		==New backup system==

import>Cen1001 at 09:42, 29 June 2006

2006-06-29T09:42:45Z

← Older revision		Revision as of 09:42, 29 June 2006
Line 6:		Line 6:
	restores; it would be an improvement if people could access their own backups. It would also be very useful to be able to keep some backups for longer than the current two weeks.		restores; it would be an improvement if people could access their own backups. It would also be very useful to be able to keep some backups for longer than the current two weeks.

	Our existing archive server is difficult to use and in ~~any case~~ is full.		Our existing archive server is not user accessible, is difficult to use and unreliable, and is completely full.

	==New backup system==		==New backup system==