Re: Recent writing about dar

Denis Corbin <[email protected]> Wed, 28 Jun 2023 19:13:02 +0200
Newsgroups gmane.comp.sysutils.backup.dar.support
Message-ID <[email protected]>
On 28/06/2023 13:52, John Goerzen wrote:
> 
> On Wed, Jun 28 2023, Denis Corbin wrote:
> 
>> [[PGP Signed Part:Undecided]]
>>
>>
>> On 28/06/2023 05:53, John Goerzen wrote:
>>> On Mon, Jun 26 2023, Denis Corbin wrote:
>>>
>>>>
>>
>> [...]
>>
>>> Interestingly, in one test case involving a detached catalog about 500K
>>> in size, doing it this way produced a catalog a few KB larger than the
>>> one produced via the piping method I originally documented.  Not an
>>> issue for me, but I thought it was a bit odd though.
>>
>> is it the same compression algorithm and level used (if any)? Same encryption
>> protocol used (if any)?
> 
> No encryption, and --compression=zstd for both.
> 
> Command A:
> 
> dar --create - \
>    --fs-root /tmp/test \
>    --delta sig \
>    | dar --sequential-read \
>      --ref - \
>      --isolate /tmp/destmeta \
>      --compression=zstd \
>      --delta sig
> 
> Command B:
> 
> dar --create /tmp/destmeta \
>    --fs-root /tmp/test \
>    --delta sig \
>    --compression=zstd \
>    --ref +
> 

OK, I've dig into details with an simple example and followed step by 
step debugging:

when creating a backup, dar records the storage size, if compression was 
used as well as the CRC (among other things). This information is kept 
when isolating a backup.

The snapshot feature does not record the storage size (does not make any 
sens and use), compression used (same thing here) and does not record 
the CRC (the data on filesystem is not even read so the CRC is not 
calculated).

This leads for each inode a minimum of 17 bytes less of storage needed 
when using the snapshot feature (-A +)

for the rest, the information is the same using the snapshot feature or 
the method you used earlier.

> Thanks,
> 
> John
> 

Regards,
Denis
OpenPGP_signature (application/pgp-signature, 840 B) - not displayed