Restic diff cannot find "latest" or "latest-1" snapshots

Getting Help
1

I’m using the latest restic and when I try to do a diff on latest and latest-1 snapshots, then restic tells me that there are is no snapshot found. I think from version 0.17 onwards, there should be right?

output:

repository daade330 opened (version 2, compression level auto)
Fatal: no matching ID found for prefix “latest”

Restic version:

❯ restic version
restic 0.18.1 compiled with go1.25.1 on darwin/arm64

2

You forgot to include the commands you are running :wink:

Preferably also include all of their output in case theres anything else.

3

@rogierl AFAIK latest is not supported by restic diff - not even in 0.18.1. Also I think that latest-1 has been never supported.

Some open issues for reference:

5

After a succesfull backup, I would like to see the changes (new files, added, deleted). For this I need the “last two snapshots”, since the diff command requires that. Another option would be to extend the backup command with an option to just show the changes related to the previous snapshot.

6

PREV=$(/usr/bin/restic snapshots --compact | tail -4 | head -1 | awk ‘{print $1}’)
LAST=$(/usr/bin/restic snapshots --compact | tail -3 | head -1 | awk ‘{print $1}’)
/usr/bin/restic diff “$PREV” “$LAST”

1 Like
7

wow, that’s simple :slight_smile: .
Haha, thanks!

8

Well, it’s not simple but it’s a solution :slight_smile:

Note that this solution reads all snapshots twice and then still has to scan the snapshots for the correct ones in the diff call. The jq solution on the github issue I linked above IMO is the preferred way - until this is supported by restic natively:

restic snapshots --json | jq '.[-2].id,.[-1].id' | xargs restic diff

This would also still work if the output of snapshots changes for some reasons.

2 Likes
9

This is a listing from a 1.3 TB wasabi backup with the above run at the end. It started at 2:00:00 AM:

Files: 1 new, 0 removed, 16 changed
Dirs: 0 new, 0 removed
Others: 16 new, 2 removed
Data Blobs: 18 new, 18 removed
Tree Blobs: 10252 new, 10252 removed
Added: 88.705 MiB
Removed: 88.633 MiB
-------------------------------
Finished backup of wasabi Thu Jan 8 02:01:11 AM AST 2026
-------------------------------

This is a listing from a 4.2 TB backup from a local NAS, followed by a check, with the above run at the end. The backup started at 1:00:00 AM, the check started at 1:01:14 AM:

Files: 5 new, 4 removed, 37 changed
Dirs: 0 new, 0 removed
Others: 16 new, 2 removed
Data Blobs: 1129 new, 6072 removed
Tree Blobs: 12648 new, 12648 removed
Added: 1.915 GiB
Removed: 7.665 GiB
-------------------------------
Finished backup of of qnap Thu Jan 8 01:01:33 AM AST 2026
-------------------------------

This check added 19 seconds to the run. Maybe someday I’ll try it with your suggestion and see how much of that 19 seconds I can save.

10

@doscott I never said that your solution doesn’t work or that it is super slow in every use case. I just said that the command I cited is better as it is

  • faster (here the backend access and number of snapshots is relevant, not the size of the backup, try with multi-1000nds of snapshots over a high-latency/low-bandwidth connection ;-))
  • more reliable as it does not depend on an output format which is not guaranteed to be stable

There’s nothing wrong with multiple solutions. However, if there is a solution with basically only benefits, it’s IMO worth to mention this. It prevents others to get problems in some edge cases :wink:

Cheers!

3 Likes