Dar on LTO

"Petr Skoda" <[email protected]> Thu, 21 Dec 2023 06:37:06 +0100 (CET)
Newsgroups gmane.comp.sysutils.backup.dar.support
Message-ID <[email protected]>
Dear Patryk, John and Denis



I am continuing from the mail originally under another subject .




So my problem with LTO is such:




I have Tandberg LTO 6 (2.5TB uncompressed) without robot (only frive) 
connected to SAS card in a older server (Xeon E5-2620 v3 @ 2.40GHz 24 cores,
128GB RAM) . I have a number of zfs RAIDs (RAID1) on HDD with about 40TB of 
science (astronomical) data. - results of some machine learning experiments,
  tens of millions of small files - spectra and also larger images - tens of
MBs large )




I am also making mirror of big spectra surveys - so 10+ mil of files about 
100kB large are added 2-3 x per year...




When I tried to make a full backup of this wealth it was challenging ...

The logical idea was to use combination of tar and dd ... I tried to split 
the big tar to 2.5TB slices etc ... The machine with LTO was on another 
computer connected by 1GB net... 

I wanted to compute md5 sum and store it as the first file . All of this 
gradually failed (impossible to finish the backup during several days .... 
just computing md5 took a week) 




Then I have discovered dar .  I tried to use direct pipes on IP ports to 
send the data to the machine with LTO ... slow - without the big cache 
impossible.




So final results of my experiments (I will shorten it) :

the LTO drive must be on the local computer. There must be a big cache 
(several TB) on RAID 0 (to speed the transfer ) ....

All the data must be prepared on that cache and then written to the tape as 
a single file (the machine should not seek small files ) ...




Another problem is the block size .... after some tests it seems that 32MB 
or larger is needed (if using tar cvf the the default is 10240 bytes ...    
recommended parameter tar cvfb 512 is minimum - or dd if=file of=/dev/nst0 
bs=256k ) but the larger the better ...




The compression is a question ....  apparently the compression switched on 
LTO (must be special version of mt task supporting compression) can cope 
with the data flow easilly - and dar_split (thanks Denis  for the FAQ about 
it) can detect the end of media and wait for human intervention.




So  far I had to end my experiments (temporary)  creating a big dar archives
on the RAID0 cache (20TB) and then send it to tape using the command 




cat mybigbackup.1.dar | dar_split split_output /dev/nst0 




and I read it 




dar_split split_input /dev/nst0 | dar -l - -0 




(-l is for listing - checking) 




I tried to play also with slices (for John) and compress them by gzip bzip 
etc ... 

Very slow .... 

Every backup was split into 2.5TB slices (I have switched the LTO 
compression off) and the slices were directly written by dd 

I also played with mbuffer  - but it seems not to help in cases when you 
want to seek files ... When the file (2.5TB) is on cache, it makes no sense,
as the dd directly to tape seems to be faster ....




I did not yet use dar for differential backups (I use it only for full large
backups) 

so far. I would like to play with dar_manager  (I already tried to play with
catalogues).




But now I would like to return to the dar again in a more advanced usage 
pattern.

My wish is to have a number of slices and the separate catalogue, which will
tell me which slices (i.e tapes) I should use to get a small subset - e.g. 
directory with one observing night ...




So the no-last-slice would be nice - but it does not work in sequence mode .
..

In addition - having a lot of tapes with different contents (e.g. part 
written by dd, tar  ..) it would be excellent to be able to read as a first 
file of each tape  and see it is a dar slice number xxx from large backup 
named (e.g. /home/bigdata) .

But as I understand it is currently not possible to read from any slice of 
dar the metadata directly.




So this is in short my current experience with LTO and dar.




I must also emphasize that I do not want to have tape written by some 
enigmatic format of any tool as bacula. Simple after years I will load the 
tape, use a dd if=/dev/nst0 of=file bs=512 (or larger) . And from the file I
will see the format, contents etc ....

That would be optimal.




All the recommendations about better housekeeping are nice but it practice 
you have tens of tapes after years and to remember what is on it is 
difficult. The catch is in LTO function - if you do not know how to read it 
(even the correct block size) the tape may look as empty ... gives reading 
errors etc ....




So I am looking for getting advice how to optimally use dar for storing 
large amount of data  (so far all tricks etc work only on small backups, but
the 2.5TB file which is being written in a optimal way about   140MB/s  
(with compression 220 MB/s peak) takes about 4 hours / slice - it is time 
consuming to try various dar options, combinations of mbuffer etc ....




I have also notice that dar_split can replace mbuffer (Denis claims it) and 
has even buffer size a speed limitation parameters ....

But my experience says it is best to leave it on default.




Best 




Petr