Re: Huge archive and last slice

Denis Corbin <[email protected]> Wed, 13 Dec 2023 19:57:45 +0100

Newsgroups	gmane.comp.sysutils.backup.dar.support
Message-ID	<[email protected]>

On 13/12/2023 15:05, Raoul Bonnal wrote:
> Hi Denis and John,
> I read again the docs and your blog, John.
> I tried multiple times and dar always requires the last slice.
> During the archive creation I specified the on-the-fly generation of the 
> catalog; later I created an isolate catalog from the original archive
> 
> Here https://github.com/rjpbonnal/dar-tests/tree/main 
> <https://github.com/rjpbonnal/dar-tests/tree/main> I tried to document 
> everything.
> If there is some mistake on my side I can not spot it.
> 
> R.

Hi Raoul,

I could reproduce this behavior and I was wrong: dar needs either the 
first slice in sequential read mode or the last slice in non-sequential 
read mode.

These contain the overall archive format information: compression algo 
used, whether if ciphering is used,...  and some other information 
needed to read the backup.

I cannot even say this to be a bug as it is per design... though it is 
very annoying in your context, because you have huge slices.

An alternative could be to use smaller slices for the cost to drag the 
last slice not be be as big as 500 GB... and store many smaller slices 
in place each big one.

But let me see whether it is possible to rely on the first slice when an 
isolated catalogue has been provided to read a backup. As you can define 
the first slice size independently of the others, it can be chosen small 
and still large enough to contain whole archive header.

Sorry for the wrong information provided yesterday.

Cheers,
Denis

> 
> 
>

OpenPGP_signature.asc (application/pgp-signature, 840 B)