Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restic uses `mtime` to detect file changes, which can miss changes. #2179

Closed
d3zd3z opened this issue Feb 21, 2019 · 8 comments

Comments

@d3zd3z
Copy link
Contributor

commented Feb 21, 2019

Output of restic version

restic 0.9.4 compiled with go1.11.4 on linux/amd64

How did you run restic exactly?

see below for the exact commands I used. Repo is local, and no other arguments are given to the backup command.

What backend/server/service did you use to store the repository?

Local.

Expected behavior

Follow the script, and expect restic to backup the given file after it has been modified.

Actual behavior

"Files: 0 new, 0 changed, 4 unmodified"

Steps to reproduce the behavior

echo "Hello world" > a.txt
echo "hELLO WORLD" > b.txt
touch stamp
cat a.txt > hello.txt
touch -r stamp hello.txt
restic -r /tmp/test-repo -p a.txt init
restic -r /tmp/test-repo -p a.txt backup .
sleep 10
cat b.txt > hello.txt
touch -r stamp hello.txt
restic -r /tmp/test-repo -p a.txt backup .

Do you have any idea what may have caused this?

mtime should not be used to determine if a file needs to be backed up, ctime should be used. Worst case with ctime is that restic will needlessly read/hash the file to determine if it has changed. By using mtime it can skip backing up a file.

I have seen the Debian package manager, specifically, replace a file with a different file, and put the mtime back to the same value.

If I add -f to the backup command, the file will indeed be backed up.

Do you have an idea how to solve the issue?

Ideally, use ctime. Maybe use both, or provide an option, but ctime is really what should be used. It would probably have to revert to mtime on a filesystem that doesn't have a ctime.

Did restic help you or made you happy in any way?

It makes me happy that it otherwise seems to reliably back up my files.

@aldem

This comment has been minimized.

Copy link

commented Mar 14, 2019

Using mtime introduces another issue - changes in metadata only, like owner, group, modes, POSIX ACLs and any of extended attributes are not detected at all.

Option -f helps, but it takes ages to backup huge filesystem, as it simply is equivalent to initial backup - for instance, in my case (ca. 35G of data, over 600K files) it takes ca. 1.5h to make first backup, then less than 10m for every snapshot, but with -f it always runs more than 1h.

@ifedorenko ifedorenko referenced this issue Mar 15, 2019
2 of 7 tasks complete
@fd0

This comment has been minimized.

Copy link
Member

commented Apr 23, 2019

Using mtime introduces another issue - changes in metadata only, like owner, group, modes, POSIX ACLs and any of extended attributes are not detected at all.

Hm, what do you mean? All the checks mentioned so far (mtime, ctime as implemented in #2212) are only used to determine whether or not a file needs to be re-read. The metadata including ACLs is always freshly loaded and written to the repo. If it hasn't changed since the last backup, restic's deduplication takes care that it isn't saved again. If anything has changed, the metadata is saved in the repo.

Do I miss anything?

@fd0 fd0 added bug enhancement and removed bug labels Apr 23, 2019

@aldem

This comment has been minimized.

Copy link

commented Apr 23, 2019

@fd0 What I mean is that if only metadata has changed, mtime is not modified at all, thus any changes in metadata only will not be carried out to backup, as file is not recognized as changed at all, at least it was like this in 0.9.4 and still like this in 0.9.5 (just tried). I have recorded session that demonstrates this (using chown and backup again).

Once #2212 is implemented, then it should work (I hope), but in current released versions it does not, unless --force is used (but forcing re-read of everything is too expensive).

@fd0

This comment has been minimized.

Copy link
Member

commented Apr 23, 2019

@aldem oh wow, now I understand and I'm able to reproduce it. I think that is a (separate) bug (and a regression) of the new archiver code introduced with 0.9.0. I'll investigate...

@fd0

This comment has been minimized.

Copy link
Member

commented Apr 23, 2019

It's a regression, it works correctly with 0.8.3. I'll open a new issue and fix it.

@fd0

This comment has been minimized.

Copy link
Member

commented Apr 23, 2019

This is tracked as #2249

@aldem

This comment has been minimized.

Copy link

commented Apr 23, 2019

@fd0 Thank you, this was a real show-stopper.

I have found this ticket and then #2212 so I thought this is not implemented yet, that's why I didn't file a bug report.

@fd0 fd0 closed this in #2212 Apr 25, 2019

@DurvalMenezes

This comment has been minimized.

Copy link

commented May 24, 2019

Please excuse me, but shouldn't we be giving more warning to users about this problem? Something along the lines of "ATTENTION: all your backups made with restic <= 0.9.5 could be missing changed files!".

I only found about this after being hard bitten (costing me almost a full day of work, and a lot of peace-of-mind, trying to hunt down apparent corruption between a saved ZFS snapshot of a directory and its restic restore'd copy)

I think the seriousness of this goes beyond just driving crazy someone that checks everything (ie, SHA checksum for restored files) like me, as changes that should have been backed up are being missed – if anyone needs to recover one of these files from backup (ie, operator error, disaster recovery, etc) he/she will, without any warning, just get an older, outdated file :-/ and in such a scenario, ie after the original file is lost, it is lost forever: there is obviously no way to recover it from a restic backup 😦

I made a separate post about it in the forum, but I think this should figure more prominently somewhere, perhaps in restic's website or even at the download page.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.