[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: LVM snapshot as a backup method
Pavlos Parissis wrote:
PP> Well 20M entries in 600GB of db is the reason of the delay.
OK; that is quite large.
DG> A clean way to do this would be to set up a slave whose
DG> sole purpose is to replicate from the main database,
DG> freeze, back-up, rinse and repeat.
PP> That was my initial thought as well but I can't use another
PP> server for operational reasons.
You mean you have to make this backup but there's no budget for doing it
properly? Assuming you only need to back up a few times a day, a
low-spec or recycled server will be enough.
PP> I've just made a backup using LVM snapshot like this (for testing only)
PP> 1) add 100.000 entries
PP> 2) create 2 lvm snapshots, one for db and for logs
PP> 3) mount the LVM snapshots and rsync the data to another disk
PP> 4) umount and delete LVM snapshots
PP> 5) stop the LDAP
PP> 6) delete all the dbs and logs
PP> 7) rsync from the backup dir
PP> 8) db_recover
PP> 9) start ldap and check if all entries are there
PP> It worked but I want to do more tests, like load a test of LDAP
PP> Write operations while the LVM snapshot is being created and few
PP> other things
This may well work, but each backup you make by doing an LVM snapshot
underneath BDB takes a similar gamble as pulling the power cords out
from your server while it's running. Most of the time, the database
will be recoverable, but you can bet that when it matters it won't be.
If you automate the process of taking, *testing* and archiving these
snapshots such that you always have a known-good, recent-enough copy,
you will probably be OK. But I would not be comfortable with this as a
backup strategy for valuable data. I would prefer a second machine, or
failing that a second instance of OpenLDAP on the same machine.
Cheers
Duncan
--
Duncan Gibb, Technical Director
Sirius Corporation plc - The Open Source Experts
http://www.siriusit.co.uk/
Tel: +44 870 608 0063