Re: dar_manager - incremental backups and removed file

"J. Roeleveld via Dar-support" <[email protected]> Mon, 15 Apr 2024 07:04:20 +0200
Newsgroups	gmane.comp.sysutils.backup.dar.support
Message-ID	<2183431.irdbgypaU6@persephone>
Hi Denis,

I am replying to both in this single email.

> we should check all the dates, not only mtime, but also used ctime for 
> EA and FSA, which does not show here, do you confirm that there is just 
> one column of date displayed for the previous dar_manager output?

Yes, I only see the one date.

On Sunday, 14 April 2024 21:01:16 CEST Denis Corbin wrote:
> I review code and did a test to double check, but could not find any 
> problem:
> 
> dar_manager -B base.dmd -f bash
> Warning: using insecure memory!
>          1       Sun Apr 14 20:21:42 2024  saved           absent
>          2       Sun Apr 14 20:21:42 2024  present         absent
>          3       Sun Apr 14 20:21:42 2024  present         absent
>          4       Sun Apr 14 20:23:37 2024  removed         absent
> 
> No warning showed. I just realize that dates are evaluated a the 
> nanosecond accuracy, but the display has only the second as precision, 
> thus this may be the reason of the warning while you see no difference.
> Unfortunately there is no way to get this information except restoring 
> files.

The backups I register into the database are taken at a daily interval and the 
files are unlikely to be touched.

> For the archive #1 #2 and #3 they should have the exact same date, else 
> dar would not have resaved the files as the modification date (which is 
> shown here) is taken into account, amount other things, to decide to 
> resave the file's data or not (here "present" means mtime did not changed).
> 
> The last archive is the removal of the file, in your case this is quite 
> weird to have the exact same date (compare with the above list). Here 
> why I find this weird:
> 
> The removal date is taken from the last modification date of the parent 
> directory, which should be updated when the directory content is 
> modified (new entry or removed entry as here). In summary the following 
> events took place:
>   - the parent directory was created at time T0
>   - the file was created at time T1,
>   - you complete the three backups (#1, #2 and #3) and completed backup 
> #3 at time T2. Making three backups in a row should take more than one 
> second even in the worse case where you create them right after the 
> previous one (which should be quite strange idea, by the way).
>   - the file is removed at T3
>   - you create the last backup at T4 which records the entry as deleted
>     and use as date the mtime of the parent directory which should be at 
> least T3.
> 
> we have TO < T1 < T2 < T3 and even T1 + 1 < T2

As you mention the directory:
$ dar_manager -B zdata_os_services_binhost_root.dmd -f usr/share/fonts/
liberation-fonts
        1       Thu Jun  3 15:32:10 2021  saved                                 
absent  
        2       Thu Jun  3 15:32:10 2021  present                               
absent  
        3       Thu Jun  3 15:32:10 2021  present                               
absent  
        4       Mon Apr  8 08:13:39 2024  present                               
absent  

$ dar_manager -B zdata_os_services_binhost_root.dmd -f usr/share/fonts/
liberation-fonts/.uuid
        1       Thu Jun  3 15:32:10 2021  saved                                 
absent  
        2       Thu Jun  3 15:32:10 2021  present                               
absent  
        3       Thu Jun  3 15:32:10 2021  present                               
absent  
        4       Thu Jun  3 15:32:10 2021  removed                               
absent  

The directory did get a new date, but the file has not been marked as changed 
(if I read the output correctly)

As this particular partition and system is not too critical, I can share the 
catalogues and database with you directly?

> the removal date for #4 (T3) should thus be more recent than for #1, #2 
> and #3 (T1). But as this is not the case, I *suspect* that directory 
> mtime to not be modified after directory creation, which date (T0) is of 
> course older than the date of #1, #2 and #3 (T1).  In this scenario, if 
> for example the data was restored, the parent directory and its content 
> could be created in very short time by dar, having an equivalent visible 
> data (less than a second of difference: T1 - T0 < 1) but still different 
> (T0 < T1), where from the error reported by dar_manager as this would 
> result in this in the dar_manager database for that file:
> #1 T1
> #2 T1
> #3 T1
> #4 T0
> 
> what filesystem is used? Which option have been used to mount it?

The filesystem:
# mount
/dev/xvda1 on / type ext4 (rw,noatime,discard,stripe=2)

I have several systems using the same distribution, but only this particular 
one is showing the problem.

--
Joost
signature.asc (application/pgp-signature, 488 B)