On 06/06/2012 09:10 AM, Florian Kaiser wrote:
> That said, I understand the only way to actually verify all increments
> is to subsequently call verify-at TIME for all given TIMES you have
> increments for. Is that correct? It does not really sound
> thought-through and I guess it is a very time consuming process, even
> on small to midsized repositories given the typical amount of
> increments is likely to be 30 days or more.
You'd better believe it. I keep daily backups going back one year and
monthly backups going back "forever".
The way I handle it for the dailys is that once a week I do a verify for
each of the 8 most recent daily backups. That is enough to verity that the
most recent part of the increments chain merges properly with the older
increments. I do this as part of a weekly process that synchronizes my
"active" backup drive with another drive that is kept in more secure
storage. What I've found is that on a quad-core machine I can run 8
simultaneous "rdiff-backup --verify-at-time" processes in almost exactly the
same time that it takes to run a single verify. The commonality of file
access means that one process has to wait for the disk drive to read a
block, but the other 7 processes find that block already in the kernel's
cache. For the most part, the 8 processes stay beautifully in sync.
Then, once a month I make a monthly backup (separate archive, same drive),
do the "synchronize and verify" with the second drive, and then rotate that
second drive with one that is kept in offsite storage. Updating and
verifying that other drive that is now a month out-of-date is literally an
all-night process since a full month's worth of increments for several
systems must be checked.
It's far from ideal, but it's the best I've come up with. I have the
process automated to the point that I just have to tell it "sync drive A to
drive B" and go to bed.
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.