I see. My understanding is that backup operations are purely additive. “Half-baked” restic repositories are normal between the start and end of a backup, and a copy of the repo in that state is not harmful or broken, either.
In the “half-baked” state,
restic check will report that there is extra data in the repository. If it’s because a backup is not yet complete, you should not yet run
prune until the backup is complete, otherwise you will have to start the backup over. (Most scripts that I’ve seen which automate restic don’t consider this, potentially causing data loss )
Having a repo in a “half baked” state is not an error, certainly not a fatal error; and next time you do the file copy, if the backup has finished, the copy will naturally repair itself. If the backup never finishes and you need the partially-finished snapshot for what data it does have, there’s a new
restic recover command that will be coming out soon which can make a new snapshot based on the “extra” data in the repo.
So, yes – read operations during a backup are safe. Even certain writes (“backup writes”) are safe to do concurrently in a restic repo.
@fd0 can correct me if I’m wrong – I might be, as always.
Incidentally, have you checked out Relica? It’s a backup service I’ve developed that provides a nice GUI for restic: https://relicabackup.com – we’ll soon be working on a feature that replicates a repository to other destinations so you won’t have to worry about scripting it yourself. I’d love to know what kinds of functionality/flexibility you require here so we can consider it when we implement it!