Re: Using dar for archives to optical discs

On 31/05/2023 23:53, John Goerzen wrote:
> Thank you, Denis.  This is helpful.  Some more comments/questions
> inline:
> 
> On Wed, May 31 2023, Denis Corbin wrote:
> 
>> On 31/05/2023 17:54, John Goerzen wrote:

[...]

> Very nice!  I did some experiments with dar_manager and all this, and it
> is looking promising.
> 
> The one thing I'd like to be able to do is easily find what slice is
> needed for a given restoration.  I can do that somewhat manually; with:
> 
> dar_manager -B foo -f bar
> 
> that will give me archive numbers, which dar_manager ... -l will
> translate into filename for me.  From that, I can use dar -l -Tslice -g
> bar to get the slices for each required backup file.

that's correct. Note that for more reliable thing there is an C/C++ API 
and a python binding that could help (rather parsing the output of dar 
and dar_manager)

> 
> I did note that dar_manager -r is very helpful for actually doing the
> restore!  Nicely prompts for the last slice, then the slices it needs.
> One foible: it complains of removing a non-existent file (presumably it
> wouldn't if I used -k) but it did work correctly.

well, it depends on the context... if you backup a full backup then a 
differential/incremental after a file has been removed the differential 
backup will have an entry for that file, as a file to be removed. At 
restoration time, restoring the differential backup, dar expects to find 
that file in the filesystem (assuming you previously restored the full 
backup) and should remove it to match the filesystem state at the time 
the differential backup was made. If the file is not present, it cannot 
be removed, so no problem the result is the same, but dar is 
purist/pedantic and signals this inconsistance.

> 
>> Note that location of data and metadata stored in a catalogue correspond
>> to the amount of byte from the beginning of the backup as if there was
>> only a single slice. If the backup is sliced this is the duty of the
>> underlying "sar" object to abstract this slicing and convert these
>> absolutes offsets to slice number + relative offset, knowing the slicing
>> information of the backup (= initial slice size and other slices size).
> 
> Ahh; I gather that this is why dar_split can't be used with random
> access, because there are only two sizes stored (the size of slice 1,
> and the size of all slices >1)?

not exactly, dar_split read and write between two pipes (its standard 
input and output) connecting to dar and to a special block device (the 
tape device for example). You cannot randomly access data on a pipe 
(first in first out).


> 
> - John
>