Re: converting decremental to full backup

Denis Corbin <[email protected]>
Newsgroups gmane.comp.sysutils.backup.dar.support
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/06/2019 16:38, Matus UHLAR - fantomas wrote:

[...]
> 
> ... but seems I didn't do through the docs deeply enough ...
> 
[...]
> 
> ... because they seemed too cryptic for me.

Yes, this is the drawback of command-line when you need a rich and
flexible feature in the middle of many other features...

> but now, I hope it's documented and can be found in the net.

the reference for dar documentation is the man page ("man dar" under
Unix) which is also available online at

http://dar.linux.free.fr/doc/man/index.html

there is also some tutorials flying around which may help for commonly
used features (overwriting policy is rather an advanced feature, right),

http://dar.linux.free.fr/doc/

> 
>> last in case there is no conflict the overwriting policy does
>> not apply, this should only occur if a file has been removed from
>> time 1 to time 2 which means a entry fully saved and only present
>> in decr1, such entry is then added to the resulting archive, as
>> expected.
>> 
>> The situation where an entry is only present in full2 should not 
>> arrive: such entry would have been created at time 2 and doing
>> the decremental backup, a "detruit" entry would have been added
>> into decr1 to indicate this entry to be removed from filesystem
>> when restoring decr1 over full2, thus the overwriting policy
>> would be triggered as explained above leading to completely
>> ignore such entry.
>> 
>> I hope the explanation are not too confusing :-)
> 
> I don't think so. Thank you!

You are welcome,
Denis
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEOzEprx3d76WjfYGPCDGwvQPYsYIFAlzz5OsACgkQCDGwvQPY
sYLa9RAAtvMxq50D7ykz/F4TeJGxbRRavENNiFh/dH9z4V/xNyjlCjSLja7KqTK3
vVcM+4BvMLkcJUdOG8FzirnwvBP2cuDGGLCobQjBAfyHCU51nqiGqZFDDbpbNmH/
woOpzUiZZy9oeuirrrtN+xAbJjNFaLOBW5h+TBkStLxgJy9CJe6l+lfB8O04lK/2
UW21UFTOEXhYoOw0hGJ7U5aC573cCJKU2KbPJE3+QoAj2Dv1nU4txalXz2te3i7J
6Ds/lrDsKchEo6m05tBRuEJ8KpNxN3gpmKLSADap5Xlhx9z6NJUmS1pyGmkBzpLf
xl95yq9nVCY1tQkAn8QKn0dfibMjfXMoKOgYWmSWdEavPq95A9i+VjAj8QsLfDyV
uUuEN8p+lt4u+SuHv2HnkJ6WwPZfByTSNtyLDrI68ERk6dxYqYz3M79aZ8OTvbas
nxJaEFztpoHFTSm90N3fixBuPsgiE4Xda3Prh9ioUDoBXwt1RrvCMdWBNOiRn1jh
Q6S2/YCm4wp5DhERt4PwHU33sUyl2tARwAtQkBmYunF+TljxUHcSAzAY3U9XmLsy
FaL6xSkWXI+izBAI31liFwoiV4Atuywz0kA+FZKPU/6CaNsNydjTuxRM9MgKGczH
N+/U4SsQG8elpTcKihr7rO+D5qBz55Q0eCZ5y+8GrWzUwgeB2+8=
=9EJA
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.