'backup' and 'diff' command have different summary

Getting Help
1

Hi!

I’ve created a backup using this command:

# restic backup --one-file-system /

using parent snapshot 284dfc67

Files:          59 new,   370 changed, 263450 unmodified
Dirs:            2 new,   134 changed, 35532 unmodified
Added to the repository: 321.392 MiB (151.141 MiB stored)

processed 263879 files, 213.073 GiB in 0:18
snapshot a3be94ce saved

After that, I’ve run ‘diff’ with the previous and latest snapshot:

# restic diff 28 a3

comparing snapshot 284dfc67 to a3be94ce:
[..]
Files:          59 new,    37 removed,   350 changed
Dirs:            2 new,     2 removed
Others:          0 new,     0 removed
Data Blobs:    460 new,   467 removed
Tree Blobs:    115 new,   118 removed
  Added:   321.392 MiB
  Removed: 366.118 MiB

There are 59 new files. Both commands return the same number.

backup reports 370 changed files. I guess this includes also deleted files?

diff reports 37 removed and 350 changed files. The summary of both is 387. So my guess that backup reports both deleted and changed files in one number is not true.

Why do both commands report different amounts of “changed” files?

Edit: I am using restic 0.18.1

2

When `restic backup` runs, it reports changes from the perspective of what’s currently on your filesystem compared to the parent snapshot. So “370 changed” means 370 files that existed in both snapshots but had different content/metadata.

When `restic diff` runs, it’s comparing two complete snapshots and showing you the full picture: files that were added, removed, AND changed between those specific snapshots.

The “350 changed” from diff represents files that exist in both snapshots but differ. The discrepancy (370 vs 350) likely comes from:

  1. Files that were modified AND then deleted during your backup operation

  2. Timing differences in how the commands process file changes

  3. Possibly some files that were detected as changed during backup but when comparing the final snapshots, show up as removed instead

    The `restic diff` output is generally more accurate for understanding what actually changed between two snapshots.

Hope that helps. Merry christmas!

2 Likes
3

When restic backup runs, I suspect it to display changes and additions w.r.t. the parent snapshot and expect the created snapshot to contain exactly these displayed changes.

And this means that restic diff on the parent and the created snapshot (as @richard did run) should also show the same differences.

For me this looks like a bug - either in the output of restic backup or in restic diff.

Merry christmas!

1 Like
4

My earlier answer was off @alexweiss, after digging around I found this thread which has more information.

The difference: restic backup counts a file as “changed” if content or metadata changed, while restic diff by default only reports content changes.

@richard, try restic diff --metadata 28 a3 (your two snapshots) and you should see additional files marked with U (metadata updated). That should account for the 370 vs 350 gap.

3 Likes
5

Hi. Thank you both for taking time to look into this! Unfortunately I’ve deleted the snapshots used in my initial question.

So I took the last two backups to check again and try with your –meta-data suggestion.

Here are the outputs:

using parent snapshot e6719351

Files:         206 new,   325 changed, 263735 unmodified
Dirs:            6 new,   195 changed, 35550 unmodified
Added to the repository: 7.345 GiB (7.142 GiB stored)

processed 264266 files, 213.101 GiB in 14:14
snapshot 1dd0dcc1 saved

# ------------------------------------------------------------------------------

restic diff --metadata e6719351 1dd0dcc1

repository c479dc32 opened (version 2, compression level auto)
comparing snapshot e6719351 to 1dd0dcc1:

[0:00] 100.00%  23 / 23 index files loaded
[..]
Files:         206 new,   314 removed,   193 changed
Dirs:            6 new,    10 removed
Others:          0 new,     0 removed
Data Blobs:   5401 new,  5336 removed
Tree Blobs:    172 new,   175 removed
  Added:   7.356 GiB
  Removed: 7.345 GiB

# ------------------------------------------------------------------------------

# Count what happened to all files/directories separately: + - U M T ?

# 212 new directories and files - that's fine
restic diff --metadata e6719351 1dd0dcc1 | grep -P '^\+\s' | wc -l
212

# 324 Removed directories and files - that's fine
restic diff --metadata e6719351 1dd0dcc1 | grep -P '^\-\s' | wc -l
324

# The file's content was modified
restic diff --metadata e6719351 1dd0dcc1 | grep -P '^M\s' | wc -l
193

# Metadata (access mode, timestamps, ...) for the items were updated
restic diff --metadata e6719351 1dd0dcc1 | grep -P '^U\s' | wc -l
329

# No type was changed
restic diff --metadata e6719351 1dd0dcc1 | grep -P '^T\s' | wc -l
0

# No bitrot detected: The file's content has changed but all metadata is the same
restic diff --metadata e6719351 1dd0dcc1 | grep -P '^\?\s' | wc -l
0

The backup command shows 325 changed files + 195 changes dirs = 520

The diff command shows 193 changed files, but no changed dirs?

Even with --metadata, the numbers doesn’t seem to match between the backup an diff command.

6

Hey @richard, hope you’re enjoying the holidays.

TL;DR: restic backup uses metadata to detect potential changes, restic diff shows what actually differs. Files detected as “changed” may end up as M (content changed) or U (only metadata changed) in diff output.

After checking the restic docs again, here’s what I suspect is happening:

How restic backup detects “changed”:
It uses metadata heuristics, mtime, ctime, file size, and inode number. If any of these changed, the file is marked as “changed” and re-read. It doesn’t compare actual content.

How restic diff reports changes:

  • M = actual stored content differs between snapshots
  • U = only metadata differs (content identical)

(See: Backing up — restic 0.18.1 documentation )

Why the numbers don’t match:

Your backup detected 325 files as “changed” based on metadata heuristics. But when diff actually compared the stored content:

  • 193 files had real content changes → M
  • ~132 files had metadata changes that triggered backup’s detection, but identical content → U

This would be expected behavior. A file’s mtime can change (triggering backup’s “changed” detection) even if the content is the same, for example, if a file was touched, overwritten with identical content, or restored from another backup.

The 329 U entries would include both those ~132 files plus directories with metadata changes (explaining your 195 changed dirs).

7

Thank you for the detailed explanation! That makes sense. :+1: