"Simon Wistow" <[EMAIL PROTECTED]> wrote: > On Wed, Jul 25, 2007 at 05:19:31AM -0400, Michael McCandless said: > > It's somewhat spooky that you have a write.lock present because that > > means you backed up while a writer was actively writing to the index > > which is a bit dangerous because if the timing is unlucky (backup does > > an "ls" but before it can copy the segments_N file a commit has > > happened) you could fail to copy a segments_N file. It's best to > > either pause the writer for backpus to occur (simplest) or make a > > custom deletion policy that safely allows the backup to slowly copy > > even while indexing is continuing (advanced). > > Sorry, I should have been clearer - I took the backup of the state of > the index when the machine restarted after the crash. I did have another > backup from a day or so ago but I was hoping to not have to reindex a > days worth of data (which is alot).
Ahhh, OK. But do you have a segments_N file? > Our backup strategy is currently - > 1) Stop the writer (and let write tasks queue up) > 2) cp -lr indexes indexes-<date> > 3) Restart the writer > > Is this something approximating best practice? Yes, this is perfect. This is the "simple" option I described. The more complex option is to use a custom deletion policy which enables you to safely do backups (even if the copy process is slow) without pausing the write task (indexing). Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
