New to restic, basic question: should it rescan all files everytime?

Getting Help
21

Hmm, even if fat32 only has second-resolution timestamps, that shouldn’t matter for the backup. Restic would still store the timestamp will nanosecond precision, but second to nanosecond conversion is deterministic and lossless. Thus if the timestamps are unchanged otherwise between snapshots, then they shouldn’t be a problem.

1 Like
22

I ran into fat timestamp issues a long time ago syncing fat to ntfs. My memory was 2 seconds, and the following indicates such:

23

Ok, so motivated by stirring up some discussion here, I created a test scenario, which was successful. After that I formatted the full disk from fat32 to ext4, did a complete restore of 250GB over SSH (and i that way proofed that a full restore works :slight_smile: ), did a full backup again… and now it seems to work! Did a couple of snapshots, even after reboot, and they all go like this:

Files:           0 new,     3 changed, 15471 unmodified
Dirs:            0 new,     7 changed,  1456 unmodified
Added to the repository: 7.623 MiB (1.923 MiB stored)

processed 15474 files, 248.955 GiB in 0:16
snapshot e0d80d6a saved

So happy right now.

In my very limited understanding that means: Fat32 is the culprit. Should this be mentioned somewhere in the Docs maybe?

24

This fat32 disk is your backup source? Correct?

25

Yes, it was. Now it’s an ext4 disk.

26

Let me rephrase: From my point of view (of limited technical understanding), it seems that if my hypothesis is true (that fat32 can cause issues such as the one I experienced), this should be mentioned in the documentation. Currently, the term “fat32” does not even appear in the documentation at all.

27

This requires further investigation to confirm the root cause. I don’t see how truncated timestamps could cause repeated rescans during backups. Timestamps with second-granularity are not a problem as long as they don’t change between snapshots.

What could change is the inode. But according to the first reply here, --ignore-inode doesn’t work, which effectively also rules out inodes as root cause. So, I’d expect that something rather weird is going on here. We shouldn’t add a note to the docs before the root cause has been confirmed.

1 Like