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-----