sync & backup

[Mark Adamson <adamson@andrew.cmu.edu>]

  I've been looking into disaster recovery for our OpenLDAP server, and
I'm trying to figure out a good way to backup the database files. If the
slapd server is running, it will have the db files open, possibly with 
memory cached objects. To do a reliable backup of the db files, the slapd
server process would have to be shut down.   Are there alternatives?

  An alternative is to create a "readonly pause" mode in the slapd
server. A signal is sent to slapd, it does a sync call on the db files and
blocks further write access to the db files until another signal is
received. Read requests from clients could still be processed, but write
requests would block.
  This is probably not hard to implement in the Berkeley db system. It
would require a lock_get() and lock_put() call around the ldbm_store() 
code, and then add a ldbm_pause() and ldbm_unpause() functions. The front
end would use 2 signals (e.g. SIGSTOP and SIGCONT) and would call a new
function pointer be->be_pause and be->be_unpause for each backend that
supported it.  There would also be some lock implementation code in the
backend initialization function.
  The ldbm_pause function would obtain an exclusive lock of the db, sync
the db, then use lock_vec() to downgrade to a shared lock. The
ldbm_unpause() function would release that shared lock. ldbm_store() would
block against that shared lock in its lock_get().  The other ldbm_*
functions, which are implicitly read only, would NOT use lock_get(), so
that the ldbm_store() function is not serialized against them.

  Now when I want to backup the db, I "readonly pause" the slapd process,
watch the log for a "sync complete" message, copy the db files aside, then
unpause it. The slapd continues to receive requests all along, existing
connections stay active.


  Useful?  Glaring errors? Deadlocks?  Better ways to backup the db files?


-Mark Adamson
 Carnegie Mellon