Re: Couple of questions regarding dar

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

in complement of Mihai's explanations:

1) yes, --fs-root /foo/bar and --fs-root /foo/bar/ are equivalent
and defines the root of the filesystem to backup (thus saved path are
relative to it).

you can restrict the backup to /foo/bar and have the "bar" part of path
stored in the archive by doing that way:
	dar --fs-root /foo --go-into bar

it will save the same thing as using --fs-root /foo/bar but all the
archive/backup content will be in a "bar" directory.

2) dar use an internal cache buffer, in addition compression and
encryption algorithm, when used, also add each an additional buffer
layer. But in any case you should see dar writing and reading
archives/backups slices large blocks of data after large block of data
around 51200 bytes or twice this size (it also depends on what the OS
supports).

dar_split also uses buffering (the maximum supported by the OS when
this one provides information about that max value, else 102400 bytes)

adding mbuffer between dar and dar_split does not bring performance
gain to my point of view. As mentioned by Mihai this however will not
cause any trouble, right.

3) in complement again, to have dar asking a password on stdin when
creating an archive (it will do that automatically when reading an
archive) just use '-K :' or if you want to specify the encryption
algorithm -K aes256:

You also have the possibility to add the "-K aes256:PasswordInPlainText"
string in a file with restricted reading rights and use "-B <filename>"
option on dar command-line. This way your password will not show on
command-line and you can automate a backup process without worries.

4) lz4 and zstd are on the TODO list, benchmark comparative performance
are linked to the library libdar will rely on to provide this feature.
So if you have some info about the performances of available lz4 and
zstd library performances let me know.

5a) by -C.. -A ... you probably mean you create an isolated catalogue
from an backup and use that one as reference for further differential
backup, right?

you can feed these backup of their corresponding isolated catalogues
to dar_manager. dar_manager will help you find identifying the backup
you need to use for a given set of files (or a single file).

5b) from the outside, differential, incremental, decremental and full
backups do not differ. This is just a dar archive format with specific
information inside. As soon as you can set the correct tape at offset
of the begining of a archive and upon dar_split request use the good nex
t
tape of the backup is split over several tapes, there should not be
any problem if the data has not been corrupted on tape.

Regards,
Denis

On 28/04/2020 00:59, Mihai Moldovan wrote:
> * On 4/28/20 12:31 AM, Nils Privat wrote:
>> Can I use mbuffer for it? Is anything bad with this command?
>> 
>> dar --create - <..other options..> --fs-root /home/user1 |
>> mbuffer -P 80 -m 2G -R 140M | dar_split split_output /dev/nst0
> 
> Nothing obviously wrong. One issue might be that pipes itself are
> already buffered, but that probably won't cause trouble.
> 
> 
>> 3) To encrypt my tape backups I currently use: --key
>> aes256:PasswordInPainText I don't like writing the password in
>> plain text. To automate the backup a manual input is not an
>> option. Can 'dar' read the password from file?
> 
> This is mostly a non-issue. Since dar will take a password via
> stdin if not provided on the command line, automation can be
> achieved by pairing it with expect(1).
> 
> 
> 
> Mihai
> 
> 
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEOzEprx3d76WjfYGPCDGwvQPYsYIFAl6oVt8ACgkQCDGwvQPY
sYJsgBAAm9owaoAV9iq637Y+jxiw0gTlDvrVfhagNQO6NOMqRWGjK9+2u1yuzw3h
Q/upqvZaLDqMcuNxHaWLWn3OAbQctVNKd18dTjKats4O8jJTUddA8/vWsxOfqjkj
fbXYtciCRaZu0gMGHnGc8w0IA54T1ZdcXHwsiMogayJfu3Ss7niSAIMTgMuOeAhJ
ca2zw43Q110HFNqoWlJpHSsFdaRk/3Gz0PuKyl1qBAl5Azk/7PPHODdkwTn6Ed88
uFzDlvZyOMyRa5feO3xfowO3wHeGULV2feQT0uyd5tradBOOJSVzSL0u5HYbwNWP
H9XFXRnbOECWr07vPELBN8UKDo4hMD8bz60OnjZyScfBOInPvI5YJAGXpmmeQL6N
hChD4VJ95RdGVfNqjQtNnAj8hNmQ/j2/21SjBOEs/exPd2offUGPgvdBhzd+iaG9
d3b3HSx+W+IUUXO/GWR6u5hJsmQpG3pg19Y43HBViHmO6LEjtHW9W5hECJmE5zbY
pDz6GsoPtSD1muoTw0A0mXBnvLMgliq6alTc9Qb/8WN0G1gTMNWAb1Iv23eu34zJ
RCtvwt31PwYXD7KNhTRajJzIgzJV1z8SSeHzS3Va6FFU8GowRlaWyIbi7zx8JdoH
0QVokWtlc5bycsQDAs05LRbqchb9Jn0lqvUKfvMo+vaHHDcumGU=
=v548
-----END PGP SIGNATURE-----