* John S. Bucy [2005-01-31 16:14:59 -0500]: > I'd like to use something like the following as a way to get > fine-grained incrementals/versioning of volumes; the mtime-based > incremental dumps presumably have to dump a whole file even if you > only change 1 byte. > > I'm thinking of the following protocol: > > 1. take a full volume dump daily
Unless you're working on the file server, this could generate a lot more network traffic than doing the incrementals. In any case, it will generate more disk I/O. > 2. use a (smart) binary diff system like rdiff (xdelta3?) > to generate a delta from the previous day's full dump > 3. delete the previous day's dump. > > It seems like the dumps would have to (at a minimum) have all of the > objects appear in the same order every time for this to work reasonably. Yes, that could be a problem too (but will mostly affect the size of your binary diffs, not the correctness of the procedure). You could try it and see. A diffing tool with knowledge of the dump format may be able to compensate for this, if it turns out to be a serious issue. > Thoughts? I've been glancing at rdiff-backup recently (along with a few other tools). The main advantages of vos dump are that (a) it knows about AFS-specific metadata like ACLs, and (b) it may be able to keep track of file renames within a volume (although I haven't checked that it actually does). But maybe, if one were given a tool to extract all AFS metadata from a volume, the rest could be handled with rdiff-backup's mechanism of computing xdeltas on individual files, not on the entire dumpset at once. _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
