[Gllug] Production system - Linux 2.4.24, LVM and cciss

John Hearns john.hearns at clustervision.com
Mon Jan 12 11:02:38 UTC 2004


On Mon, 12 Jan 2004, Simon A. Boggis wrote:

> I would suggest that the proposed system is only good for disaster
> recovery, because it gives little protection against user error
> destroying files (or contents) or software or hardware error corrupting
> files - you only have two backups, which isn't much history if you
> backup every day, as you should (and if you only backup once a week I
> hope you're sure that your users don't mind loosing up to a weeks worth
> of work/mail/whatever!).
> 

Well put. I agree.
"Backups" have several purposes.

* disaster recovery - scenarios such as the entire systems being stolen or 
destroyed. Or simply disks failing

* recovery of deleted user data, either accidentally or deliberately

* archival, perhaps for legal (eg company accounts) or medico-legal 
reasons (eg. medical 
records/imagery


A backup strategy should reflect the above purposes.

Just blue skying, if you (say) are in an organisation which stores oddles 
of data on RAIDs, but which also has the raw data available you might 
consider the levels of redundancy of RAID to be sufficient.
Examples might be a video company, which stores original video on tape,
or physics data all stored on tape.
Management should be aware of the time it would take to completely restore
though.

Backup tapes still have a place in this organisation - user home dirs,
mail spool must be backed up.


I think it is possible to do the archival/recovery funtion these days to
disk arrays. Me, however, I'd still like to have something in a drawer
with a date written on it.


One thing we haven't mentioned in this thread is snapshotting in LVM.
(make a snapshot copy of e.g. a database, then back up the snaphot at
your leisure).
High time I think for a reprise of the LVM talk from Alistair Kergon,
if he's available.


-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug




More information about the GLLUG mailing list