On 6. 6. 2012 17:43, Robert Nichols wrote:
[...]
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.
[...]
Thank you very much, I was not aware of "--verify-at-time". And if I
were, I would not guess that actually I can run more than one checks at
a time without cost of kernel blocking due to I/O, because I just have
not realised that it is all actually in the cache, when running
simultaneously.
Once again, thank you for the suggestions, I have updated my scripts
.
Best,
vdm
.
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
