[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Duplicity-talk] Incremental backup when data changes but timestamp
From: |
Nate Eldredge |
Subject: |
Re: [Duplicity-talk] Incremental backup when data changes but timestamp does not |
Date: |
Sun, 14 May 2023 12:55:00 -0600 (MDT) |
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