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.
If you are using rsync you don't have to store the block checksums
neighter on the server nor client. They are calculated on the server at
runtime. That's the default behavior of the rsync network protocol. I
don't know if it's possible, with rsync, to store only the delta of a
file on the server, again the default behavior is the the server have
the whole file of every version. But it should be possible to overcome
this behavior.
/René
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
