>>>>> On Thu, 14 Jul 2005 11:15:59 +0200, >>>>> =?ISO-8859-1?Q?Ren=E9_Brask_S=F8rensen?= <[EMAIL PROTECTED]> said:
René> Martin Simmons wrote: >>>>>>> On Wed, 13 Jul 2005 12:32:19 +0200, Kern Sibbald <[EMAIL PROTECTED]> said: >>>>>>> >>>>>>> >> Kern> On Wednesday 13 July 2005 11:44, Martin Simmons wrote: >> >> >>>>> On Mon, 11 Jul 2005 20:35:46 +0200, Kern Sibbald <[EMAIL PROTECTED]> >> >> >>>>> said: >> >> Kern> On Monday 11 July 2005 18:50, Phil Stracchino wrote: >> >> >> On Mon, Jul 11, 2005 at 11:44:36AM +0200, Ren? Brask S?rensen wrote: >> >> >> > Hi All >> >> >> > >> >> >> > Don't know if this is the right list to ask. >> >> >> > >> >> >> > I have been looking through the bacula documentation but couldn't >> >> >> > find anything about delta compression. Do backula support any kind >> >> >> > of delta compression ? or are there any plans for implementing it i >> >> >> > future releases ? I'm asking because it frustrates me that I every >> >> >> > night transfer one file that's over 1Gb. If I had a tool which >> >> >> > supports delta compression I could greatly reduce the amount of data >> >> >> > transfered. >> >> >> >> >> >> This is something that has been discussed in the past, but no-one has >> >> >> yet worked on an implementation to my knowledge. >> >> Kern> I haven't read about how rsync and zsync work, but I suspect that >> >> it is called Kern> delta comparison rather than delta compression since the >> >> incremental backup Kern> of only what changed is based on a rolling file >> >> signature or checksum rather Kern> than a compression technique. In fact, >> >> compressing the files can create Kern> important problems for these >> >> techniques. >> >> Kern> I don't see how the same technique can be used with Bacula or any >> >> other Kern> program that does not store the files in a directory tree on >> >> disk. These Kern> techniques seem to require having the previously backed >> >> up file available for Kern> comparison during subsequent backups. If >> >> someone has an idea how to Kern> implement this without having backed up >> >> files online, please let me know. >> >> >> >> Maybe storing the checksums of the original file blocks would suffice? >> >> That is still a significant amount of data, but less than the file itself. >> Kern> This is already done providing you enable either MD5 or SHA1 signatures. This Kern> will be used in the Base implementation. >> >> OK, but the client or director would have to keep *per block* checksums >> available online so the next differential backup can compare them. >> >> >> >> René> If you are using rsync you don't have to store the block checksums René> neighter on the server nor client. They are calculated on the server at René> runtime. That's the default behavior of the rsync network protocol. I René> don't know if it's possible, with rsync, to store only the delta of a René> file on the server, again the default behavior is the the server have René> the whole file of every version. But it should be possible to overcome René> this behavior. Indeed some versions of rsync include an experimental "batch mode" which provides part of what is needed by storing the checksums (see http://www.ils.unc.edu/i2dsi/unc_rsync+.html) but I think it still needs two complete copies of the file. __Martin ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
