Re: dar complains when creating decremental backup

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

On 04/08/2019 12:50, Matus UHLAR - fantomas wrote:
>> On 31/07/2019 19:44, Matus UHLAR - fantomas wrote:
>>> when trying to create decremental backup, dar complains per
>>> file:
>>> 
>>> % dar -+ /tmp/moj\ svet\ novovytvoreny\
>>> 1.8.9-DECR20190705-20190729 -A moj\ svet\ novovytvoreny\
>>> 1.8.9-FULL20190705 -@ moj\ svet\ novovytvoreny\
>>> 1.8.9-FULL20190729 -ad Warning: using insecure memory!
>>> 
>>> EA and FSA of file <ROOT>/moj svet novovytvoreny 1.8.9 are
>>> about to be dropped from the archive and marked as already
>>> saved, proceed? [return = YES | Esc = NO] Continuing... EA and
>>> FSA of file <ROOT>/moj svet novovytvoreny 1.8.9/level.dat are
>>> about to be dropped from the archive and marked as already
>>> saved, proceed? [return = YES | Esc = NO] Continuing... EA and
>>> FSA of file <ROOT>/moj svet novovytvoreny 1.8.9/level.dat_old
>>> are about to be dropped from the archive and marked as already
>>> saved, proceed? [return = YES | Esc = NO] Received signal:
>>> Interrupt Archive delayed termination engaged Disabling signal
>>> handler, the next time this signal is received the program will
>>> abort immediately Continuing... File selection has been
>>> aborted. Now building the resulting archive with the already
>>> selected files
>>> 
>>> I can turn off these warnings with '-w' but are they necessary
>>> by default? or do I make a mistake somewhere?
> 
> On 04.08.19 12:00, Denis Corbin wrote:
>> I suspect one of the two full backups you are basing your
>> decremental archive one does not contained EA nor FSA for saved
>> file (for some reason), can you double check that: dar -l moj\
>> svet\ novovytvoreny\ 1.8.9-FULL20190705 and dar -l moj\ svet\
>> novovytvoreny\ 1.8.9-FULL20190729
>> 
>> have consistent EA and FSA presence for files have not changed in
>> the meantime?
> 
> I don't think so. I haven't played with options other than -c and
> -g.
> 
> These two were created using the same parameters, although with
> different dar versions - I have upgraded debian from 9 to 10,
> changing dar 2.5.8 to dar 2.6.2, archive version format reports 9
> for the old one, 10 for new one.

Reading the logfile, I could not see any change between format 9 and
10 concerning EA nor FSA that could explain a difference of behavior.
As far I as remember dar binary under Debian have been built with EA
and FSA activated for a long time (10 years at least) so I'm confident
the problem does not come from the way dar has been compiled.


> 
> However when I tried create decremental from two version 9 archives
> created with 2.5.8, I got the same complaint, even when I swapped
> them (-A and -@ - just for sure) and got the same result when tried
> to create decremental versions before.
> 
> in the past I have silenced this error with -w (or -wa?) option but
> was curious if this is normal.

looking at source code, this message is issued if the file "to be
added" (from -@ archive) has no EA or no FSA while the one "in place"
(from -A archive) has some EA or FSA respectively.

This situation may be normal (all EAs have been cleared for a given
file for example) in which case this warning can be ignored and the
use of -w is OK.

However, I would double check first that there is nothing weird in the
way EA and FSA are saved: just list both archive, if you can find some
file with EA some other with FSA saved in both, there should not be
any problem.

If you want to go one step further in validation, I suggest keeping
the old full backup, restoring it in a first directory "REF" and in
another directory "DECR" restoring the latest full backup then the
decremental backup over it.

Then comparing the REF and DECR for data contents, EA and FSA. Dar can
help here by doing a crossed comparison (compare the archive content
with the restored data of the other archive):

   dar -d old_full_backup -R DECR --comparison-field=mtime
   dar -d decremental_backup -R REF --comparison-field=mtime

this way you easily compare EA and FSA presence and content, inode
metadata thing the diff command does not (it only compares data).
	

> 
> Thanks

Regards,
Denis
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEOzEprx3d76WjfYGPCDGwvQPYsYIFAl1HK28ACgkQCDGwvQPY
sYI/AhAAhoZKzFOBEQUHDfw/hMoDQIn4pU87laiBDXDbIfqRGwG4MZ/bBzxkGHNm
LAfLvuztvPaxUssjfmC00/jE8OebtcYmuRIC8tqM9JTUEgko/dK2ex70KASiG9N5
PC9oSYw3u6/v7C6UliaDHXz0gEs9/0TRw2Gpz1lzMPlvbr02YG6qT+xkN6Gylm5o
2TL665R8m1YVb9E/G8YdXVLqJY3j9B0xf2GGwq5Zi565oDFWUQ0HA+FNW8ccSno5
giGAnpAyB7kX0eOuuMR0AMZ0op0v3Ly6xk3Jjwj9wa1xZ8ev68JPiAHvre4RFEBN
EGWl164w0imuV6xbilGA92zA9qkN33cpHDK7DWTe0RMxGOihSJTSsmXe+NH9AfV8
ZT1Em9PuMGtB2elOR/9WVIkSMV+K/Wy2fyQ7oOqEslXLBVxd2hhDNl0IwP1sj56+
puzp+INrNnTjlmOJ6sa60J8eyu640QyjPmnstq6nuInACZpLAWZSKVz4ZEIEjXHT
e66LIvFqv888lPphTdgwm/on+L4wqpKjRSi6PUWpUDO4BSuxUDrEcig/PF+97BRg
uCQdLIFmQENoik+NnabqhM/xn4fkozsF2EBLENdXoSp1GE5ju3x0xLZxMxBkkI7v
eMGnSZMxCBLMRRTeMdlUMOGA0sJvHRY1v/XFONH1VsbMMKVnAbM=
=CGpp
-----END PGP SIGNATURE-----