Re: why [Saved][D] instead of [Delta][D]?

On 04/05/2021 20:35, imschmeg wrote:
> On Tue, 4 May 2021 20:10:30 +0200
> Denis Corbin <[email protected]> wrote:
> 
>> On 04/05/2021 02:25, imschmeg wrote:
>>> In another use of dar on a non-encrypted filesystem, I am using
>>> options --delta sig and --delta-min-sig-size 1M.  I have a full and
>>> a differential with that full as --ref, both with the same --delta..
>>> options.  However, when I list the differential's contents, all [D]
>>> files (those with computed deltas) in it are [Saved][D] instead of
>>> [Delta][D]. Why might that happen?  
>>
>> I would increase verbosity (-v option) to have more information about
>> what's going on during the different backup.
> 
> I will do that next.  
> 
> I just tried another test where instead of a catalogue,

You did not mentionned the use of a catalogue so far, did you?

How did you created the catalogue, does the catalogue contains the delta
signatures? If not, this would obviously be the reason why making a
differential backup from it would hold no delta patch but "saved" data
beside associated delta signatures.

I strongly suggest you re-read the paragraph "Binary delta options usage
and best practices" in the dar man page:

http://dar.linux.free.fr/doc/man/dar.html


> I created a
> differential immediately from the full, so that it would contain no
> changes (the source file didn't change between the dar calls), but
> still house delta signatures. It was much larger than the actual
> catalogue, but still much smaller (<1%) than the original full. In
> other words, I simulated a catalogue extraction, and the result appears
> to capture the delta signatures unlike the normal catalogue extractions
> either by -C or --on-fly-isolate.  Changing the source file and
> creating an incremental from that simulated catalogue works, in that
> the resulting incremental was much smaller than the full, only about 2X
> than the simulated catalogue, and shows [Delta][D] in its listing (and
> 99% compression).
> 
> Which means I have a workaround, even though it will probably be slower
> in real cases.  But I will continue to debug the issue with -C and
> --on-fly-isolate not performing similarly...
> 
>>
>> Such situation can occur if you did not provid the same -R option to
>> both backups, for example... but there may be other reasons of course.
> 
> In my test, there is only one possible fs root and only one file in that
> directory, and listing the backups show that they all captured that
> file.  In other words, I created an empty directory for the test, a
> subdirectory off of that named sub, and put a single randomly generated
> file in that subdirectory, and used --fs-root ./sub for all runs.
> 
> BTW, I am still using dar_static_2.6.14_x86_64_GNU_Linux for all of
> these tests.
>