Hi Robert, 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 .
signature.asc
Description: OpenPGP digital signature
_______________________________________________ rdiff-backup-users mailing list at [email protected] https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
