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