Re: [Duplicity-talk] Incremental backup when data changes but timestamp does not

[Nate Eldredge]

On Sun, 14 May 2023, edgar.soldin--- via Duplicity-talk wrote:

> On 14.05.2023 07:31, Nate Eldredge via Duplicity-talk wrote:

> > It'd be nice to have something more efficient and robust, though.  One 
> thought would be to check whether the ctime is newer than the date of the 
> previous backup.
>
> i wonder why rsync does not use ctime by default though. there may be a 
> reason for that. fs-standard of course mandates mod-time changes only when 
> the file is changed. c-time is supposed to be fixed.

For what it's worth, `gtar --listed-incremental` does do this - if a 
file's ctime is newer than the timestamp of the snapshot file, it gets 
backed up.

> > We could also check the birth time on filesystems that support it.  We 
> would get false positives in cases like replacing a disk and `cp -a`ing over 
> all the files (which normally would preserve mtime but not ctime), but it 
> could still be useful as an option.
>
> that sounds fishy. i don't see how a containing filesystem change should 
> trigger a recompare by default.

Maybe a better example: suppose I accidentally delete a file `foo`, and 
then restore it from backups with duplicity, tar, rsync, cp -a, or 
anything else that restores mtime along with contents).  It does not 
really need to be backed up again, since nothing is different as far as 
duplicity is concerned.  But its ctime will have been updated, since you 
normally couldn't or wouldn't restore the ctime.  So if we check ctime 
then such a file will be recompared.  Ditto for birth time.

ctime would also update in a few other cases that wouldn't otherwise 
trigger a recompare: change in hard link count, or if the permissions were 
changed and then changed back.

Personally I wouldn't mind, and would be happy to pay the cost of extra 
recompares in exchange for better assurance that changes are being picked 
up.

--
Nate Eldredge
nate@thatsmathematics.com