Re: Huge archive and last slice

Denis Corbin <[email protected]> Wed, 13 Dec 2023 21:01:58 +0100
Newsgroups	gmane.comp.sysutils.backup.dar.support
Message-ID	<[email protected]>

On 13/12/2023 19:57, Denis Corbin wrote:
> 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
> 

OK, I could make it. You can checkout the code from git on branch 
"no_last_slice". I have to test is further but it seems OK so far. I 
don't know yet where I will merge those changes, probably into branch 
2.8.x not 2.7.x, but will keep it updated beside branch_2.7.x until then.

This change leads dar to ask the first slice instead of the last slice 
only when an isolated catalog has been provided and the operation reads 
a backup in direct access mode (not in sequential read mode). In 
sequential read mode dar already fetch this info from the first slice, 
of course.

So there is changes from user point of view. Let me know if someone has 
any object to this... I can still surface this as a new parameter for 
user to decide, but would like to avoid this extra work, if it is not 
necessary.

Cheers,
Denis

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