Re: [Dar-support] backing up directly to tape

[Gour <go...@at...>]

Denis Corbin <dar...@fr...> writes:

> dar is well adapted to disk by design (where from its name :-) ), thus
> either you have local or network filesystem and dar creates files to
> them or you can use the -E option to copy the slice to a remote
> storage (scp, sftp, etc.) as soon as it is completed (the other way
> for reading, as soon as it is required by dar, still using -E option).

Strange indeed...that I 'forgot' about "D" in dar's name. :-)

> In that case I recommend not choosing a tool large slicing for you can
> avoid retransmitting too much data in case of network failure. Finding
> the adequate size is defining how many time you are ready to loose
> resending data thus knowing the expected network bandwidth with some
> simple math you can find the expected slice size.

Thanks. That's why I like the idea to use RDX media - no need to
resending since the backup will go straight to the cartridges.

> next major release (2.5.0) is expected for this year... but even if
> you migrate to RDX before, or choose another backup solution, I would
> appreciate if you could just tell me whether this "dar_split" is
> suitable to work with tapes (I have no tape device here).

I did try with dar_split, but when dar filled the first tape, it was
spitting "I/O errors" on the console while I was waiting the tape to
rewind and replace with the 2nd one.

After that, dar continued with writing, but I wonder if everything was
OK.

The problem is that I simply do not have enough space on my regular HD,
to perform the whole backup and then try to restore and check if
everything is OK.

However, today I might try to devise a backup which fills just a little
bit over one tape - iow. using two tapes - and then try to restore.

> Dar archive have redundancy checking (CRC) that will let it detect
> corruptions in an archive and skip over such corruption (you may also
> ask dar to restore the corrupted file anyway thanks to the 'lax
> mode'). But dar cannot correct such corruption, par2 *can* most of the
> time (if the amount of data lost is larger than the redundancy data
> calculated by par2, obviously par2 cannot recreate the information it
> hasn't).

That's clear.

> Seen that point, as it does not hurt adding par2 data beside dar
> slices, even 1% redundancy can help you preserve your data over time
> or over bad media... however par2 works on files so you will not be
> able to use tape except having first dar writing to disk, running par2
> from -E option or using "par2" on command-line or even once all slices
> have been created, then moving the slice(s) and its/their par2 file to
> tape.

Well, using dar with tapes is just temporary solution until I acquire
RDX which will be, I hope very soon, but, as you wrote above, it seems
that dar is definetely more suitable for disks, while tapes are, maybe,
better left to Amanda/Bacula/etc.

However, I plan to deploy par2 usage 'cause it looks the price is not
too big.



Sincerely,
Gour

-- 
It is far better to discharge one's prescribed duties, even though 
faultily, than another's duties perfectly...