Re: dar_manager - incremental backups and removed file

Denis Corbin <[email protected]> Mon, 22 Apr 2024 12:41:18 +0200
Newsgroups	gmane.comp.sysutils.backup.dar.support
Message-ID	<[email protected]>

On 22/04/2024 08:34, J. Roeleveld via Dar-support wrote:
> On Sunday, 21 April 2024 21:28:48 CEST Denis Corbin wrote:
>> On 20/04/2024 15:23, Joost Roeleveld via Dar-support wrote:
>>
> [...]

[...]

>>
>> So my question is now about the snapshot process and the way you expose
>> it to dar.
> 
> commands run (simplistically, nothing special is actually performed):
> # zfs snapshot ....
> # mount -oro /dev/zvol/.....  /mnt/darroot
> # dar .... /mnt/darroot
> 
>> Could you issue the following command for example in such snapshot:
>>
>> stat /usr/share/fonts/hack
> 
> # stat /usr/share/fonts/hack
>    File: /usr/share/fonts/hack
>    Size: 4096            Blocks: 8          IO Block: 4096   directory
> Device: 202,1   Inode: 532613      Links: 2
> Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
> Access: 2022-08-02 08:56:46.000000000 +0000
> Modify: 2021-06-03 13:32:10.000000000 +0000
> Change: 2024-04-08 06:13:39.937335727 +0000
>   Birth: 2017-10-26 11:41:16.541269703 +0000

OK, good to know the dates are rounded up outside dar and dar_manager

> 
> [...]
> 
>> In conclusion so far, the explanation of the warning issued by
>> dar_manager is caused by a loss of time precision and is not a bug in
>> dar_manager, maybe still possible a bug in dar but that is not the most
>> probable explanation IMHO.
> 
> I can't fully check the actual timeline and what happened as not all logs are
> kept this long, which currently is quite annoying. I wish I knew how to
> reproduce this. Going forward, I have increased log-retention and if it occurs
> again, I should have a better idea on how to reproduce this issue.
> 
> Looking at the output of the "stat" command, I wonder if "tar", by default,
> only stores second-level precision, leading to the ".000000000 +0000" I see
> for "access" and "modify"

by default tar stores at one second accuracy. I did a benchmark some 
years ago, comparing features of dar, rsync and tar and getting back to 
it at http://dar.linux.free.fr/doc/benchmark.html I read that you can 
enhance tar time precision using the --xattrs argument, but it also 
depends on the tar version... according to the test logs at
http://dar.linux.free.fr/doc/benchmark_logs.html I was using tar GNU tar 
1.30

> 
> The filesystem has been the same for years and the OS is simply being kept
> uptodate over time.
> 
> What does "dar" do when it sees ".000000000 +0000" at the end? Does it reduce
> the precision to match the lowest non-zero field?

Very good question! Looking at the code, dar reduces to the largest time 
unit (microsecond or even seconds), so the time precision reduction is 
probably due to dar hitting the .0000000 fractions of a second.

according the the integer type used to store the date, take the largest 
possible time unit when possible reduces:
- slightly the time needed to compare dates
- less probably the memory footprint (due to block size allocation)
- mostly the size of the resulting dar backup/archive

> 
> If the above doesn't yield anything pointing to a specific issue in dar/
> dar_manager, I would suggest we leave this as-is and wait for it to happen
> again.

OK, let's do that way.

> 
> --
> Joost
> 
> 
> 

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