Re: RSync like diff for incremental stuff
Denis Corbin <[email protected]> Mon, 15 Jun 2009 22:01:13 +0200
| Newsgroups | gmane.comp.sysutils.backup.dar.general |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Cyril Russo wrote: > Sterling Windmill a écrit : >> Have you tried rdiff-backup ? > Yes > And, even better, duplicity. > > However, all thoses software still lack a major technical feature. > rdiff-backup doesn't compress (unless you have gzip-rsyncable) nor > encrypt, so it's useless if you don't master/trust the remote host location. > duplicity compress and encrypt and use rsync, but it uses TAR > internally, so browsing a backup is a real pain (as there isn't any > catalog in the archive itself it's very very slow). > Duplicity comes with a real giant list of backend for accessing remote > storage (from sshfs, imap, webdav, ftp, S3, tahoe, local, etc...). > > I though about an ultimate backup tool that would use the smartness of > DAR (catalog / compression / encryption / incremental), but with a > optimal disk consumption (thanks to rsync). > That way, browsing the backup set would still be very fast. > > I think the unix philosophy of "One tools does one thing well", I would > let DAR create a local backup archive on a remote mounted filesystem > (like NFS, SSHFS, WebdavFS etc...). > > Anyway, how complex would it require to implement in DAR ? First, to be able to make a binary diff you must have the original binary beside the current one to compare them (actually dar relies on inode data changes to decide whether to save the whole file again or to not save it at all). Consequences is that this is not compatible with differential backup based on catalogue, the feature must thus be an option. Worse it is will be difficult to base such a backup on a differential backup. Suppose the file is already binary diffed ... how to know if the part of the file that is not present in the file has changed? Yes, using signatures (or ~ CRC) but still the risk that the file changed and signature stays the same thus changed would not be saved. The second point is that at restoration time you must not blindly patch an existing binary file with the portion of data that have been saved. The use of signature (CRC for example) done on the original file is necessary, but will not warranty that the original file is the really the same as the one over which the binary diff has been made (there is still a little chance that two different files get the same signature) and I don't see any mean to be sure that the live file to restore over a binary diff is exactly the same suite of byte as the one used at backup time, except than comparing byte by byte, thus requiring any previous diff backup up to the first where the whole data is present. But now, if the user is warned about this risk and wants to take it ... I see no problem. This was for the functional level. Seen now the implementation, this should be feasable, but at the cost of some major change in the way dar stores files. We must now not only store a suite of bytes to be copied to a brand new file, but a list of blocks with offset, length and data (an probably checksum). Well, there is a feature in the pipe that will bring some changes at this level which is the possibility to properly store sparse files [ https://sourceforge.net/tracker/?func=detail&aid=1457710&group_id=65612&atid=511615 ]. I could extend a little bit this feature to let room for CRC fields and the like (re-using the TLV class). Will lack the algorithm to inspect binary files and decide which way to define blocks of changed data. The problem here is that it will cost much more disk I/O to compare two binaries: It must first be necessary to inspect the whole files (old backup and live filesystem) to find out which amount of data has changed and which pattern do changes follow. It may well be more costly to systematically do a diff in place of a full backup if a byte every N byte has changed for example. Then, we could proceed either to full backup or binary diff backup. Regards, Denis. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKNqiJpC5CI8gYGlIRAgPmAJ0SCvF25/l5QWQudF1PpU7kzWxnegCeLywp JxJqhIVf26F8xf/ss0c5s58= =8p/S -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Dar-discussions mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dar-discussions