Re: dar_manager - incremental backups and removed file

Denis Corbin <[email protected]> Sat, 20 Apr 2024 13:25:59 +0200
Newsgroups	gmane.comp.sysutils.backup.dar.support
Message-ID	<[email protected]>
Hi Joost,

could you provide the output of 'dar -V'?

Have you recently recompiled or upgraded the dar binary used here to 
make backups on that host?


On 17/04/2024 06:55, J. Roeleveld via Dar-support wrote:
> On Tuesday, 16 April 2024 22:29:42 CEST Denis Corbin wrote:
>> On 16/04/2024 09:44, J. Roeleveld via Dar-support wrote:> On Monday, 15
>> April 2024 22:56:58 CEST Denis Corbin wrote:
>>   >> On 15/04/2024 07:04, J. Roeleveld via Dar-support wrote:
> 
> Hi Denis,
> 
>> OK, the first problem you reported about dar_manager warning is a bug.
>> Here is what produces the output with all detailed date information (new
>> -x option for dar_manager):
> 
> Ok, I'll ignore it for now. :)
> 
>> # dar_manager -B
>> database_delete_order_warning/zdata_os_services_binhost_root.dmd -f
>> usr/share/fonts/liberation-fonts/.uuid -x
>> Warning: using insecure memory!
>>    1       Thu Jun  3 15:32:10 2021 + 341379045 ns  saved     absent
>>    2       Thu Jun  3 15:32:10 2021 + 341379045 ns  present   absent
>>    3       Thu Jun  3 15:32:10 2021 + 341379045 ns  present   absent
>>    4       Thu Jun  3 15:32:10 2021  removed                  absent
>>

I observe that the backup you kindly provided, do contain different time 
precision for different files, some file have mtime in unit of second, 
some other have nanosecond precision, in the same backup, which is very 
weird.

I tried to reproduce this on a simple case, traces the code and could 
not see any place where time precision would be lost.

I still have some process to explore other backup transformation process 
like catalogue isolation, so investigation are still under process...

>>
>> The date at #4 is just lacking the sub-second information, which leads
>> it  to be considered older than the dates at #3 #2 and #1 by
>> approximativement 0.341 s. This is the cause of the warning. I will look
>> at the way the removal date is obtained and why it is lacking the
>> sub-second part, but that's almost harmless as far as I see the
>> consequences. This may be a bug in dar or dar_manager I have to
>> investigate that.
>>
>> The second problem is the fact the date of removal (over its lack of
>> precision), is not the last modification date of the parent directory. I
>> also have to investigate that. Same thing here, maybe the problem is in
>> dar or dar_manager but this is also a bug.
>>
>> # dar_manager -B
>> database_delete_order_warning/zdata_os_services_binhost_root.dmd -f
>> usr/share/fonts/liberation-fonts -x
>> Warning: using insecure memory!
>>    1       Thu Jun  3 15:32:10 2021 + 341379045 ns  saved     absent
>>    2       Thu Jun  3 15:32:10 2021 + 341379045 ns  present   absent
>>    3       Thu Jun  3 15:32:10 2021 + 341379045 ns  present   absent
>>    4       Mon Apr  8 08:13:39 2024 + 957335766 ns  present   absent

Here the mtime of the parent directory at #4 is different between what 
the dar backup stores and what the dar_manager database has recorded. I 
have found where it is done in dar_manager, but still have to figure out 
why. I guess this is related to the way dar_manager handles extended 
attributes and FSA.

[...]
> 
> --
> Joost
> 
> 
> 

Denis
OpenPGP_signature.asc (application/pgp-signature, 840 B)