Why don't use tags to find latest snapshot when backup?

As the title and the code shows , I meet a problem when in a parallel backup. The steps are:

  1. Start two process backup two different tags volume
  2. Process A has send part of indexes and Process B find all indexes for backup at the same time
  3. ProcessB deal indexes successfully
  4. ProcessA send all indexes to backend and it’s snapshot
  5. ProcessB finds latest snapshot, and it’s ID belongs to ProcessA
  6. ProcessB parses snapshot (belongs to ProcessA) and generate blob use indexes in it’s cache but cannot find the relation between index and blob, as the code shows.

So, i want to know , why not to use the tags to find latest snapshot when backup ? Different tags data is usually different.

Sorry, I actually wasn’t able to understand your issue.

Can you please give the exact commands you use and the output of the two parallel restic runs? I think that would help understanding the problem you encounter. Thanks!

OK,i explain it.
There are two processes and they are in two different hosts.
ProcessA backups and use command

restic backup --repo=xxx --tag=process=A

and finally generates snapshot ID named ‘snapshot-id-a’.

ProcessB backups and use command

restic backup --repo=xxx --tag=process=B

and finally errors are

archiver/archiver.go:756 archiver.(*Archiver).loadParentTree 371 unableto load tree 6dfaff27c049d73ab46003fab1a3be52faff296ee6cc6fbd8f47c2de7eaac845:id 6dfaff27c049d73ab46003fab1a3be52faff296ee6cc6fbd8f47c2de7eaac845 not found in repository

archiver/archiver.go:162 archiver.(*Archiver).error 371 item/: error was filtered by handler, before: “tree 6dfaff27c049d73ab46003fab1a3be52faff296ee6cc6fbd8f47c2de7eaac845 is not known; the repository could be damaged, run rebuild-index to try to repairit”, after:

And i’ve debug the reason.
ProcessB backups use processA’s snapshot as it’s parent snapshot. But processB get all indexes firstly and cache them in host, but at that time processA has not completely finished. So, when processB backups and loads parent snapshot’s tree catches error.

And what bothers me it’s when we backup, why not use tag list to find parent snapshot? Currently it’s empty tag list.

Thanks for the explanation (and especially for the error outputs), I think I got it :smile:

IMO there are two issues here:

  1. your ProcessB uses the “wrong” parent snapshot. You are right, restic only uses the hostname and path to search for a parent. Are processA and processB really running on the same host backing up exactly the same path? If not, I would suggest to you to use different hostnames (--host option) or look for your paths…
  2. The snapshot and indices are read by restic in wrong order, see List snapshots before index by MichaelEischer · Pull Request #3570 · restic/restic · GitHub. This leads to the first error.

I think if you fix 1) or use the patch given for 2) , the first error will disappear, but fixing 1) is preferred as using the right parent will speed-up your backups.

I’m not sure about your 2nd error, but this could be a follow-up error after some parallel runs leading to the first error.

Thanks for your reply.
As your mention, I use same host but different containers to backup data use kubernetes. Two processes are two different PVCs so the data is also different, but same host.
The PR can solve my problem. Thanks again.

I advise you to either manually set an artificial host with --host or do some scripting to get the right parent ID from restic snapshots.

If you in fact are fine without a suitable parent, use backup --force instead of that PR…