Output of restic version

restic 0.9.6 compiled with go1.13.4 on linux/amd64

How did you run restic exactly?

restic -r rclone:ovh:test2 -p key-restic snapshots

Output is:

Load(<key/1bd3e4429a>, 0, 0) returned error, retrying after 720.254544ms: <key/1bd3e4429a> does not exist

repeated a couple of times with changing retry times and then:
Fatal: <key/1bd3e4429a> does not exist

When using
RCLONE_VERBOSE=2 restic -r rclone:ovh:test2 -p key-restic snapshots
you see:

rclone: 2019/12/07 12:40:04 DEBUG : Swift container test2: GET /file-5577006791947779410
rclone: 2019/12/07 12:40:04 DEBUG : file-5577006791947779410: GET request error: object not found
rclone: 2019/12/07 12:40:04 DEBUG : Swift container test2: HEAD /config
rclone: 2019/12/07 12:40:05 DEBUG : Swift container test2: GET /keys/
rclone: 2019/12/07 12:40:05 DEBUG : keys: list request
rclone: 2019/12/07 12:40:06 DEBUG : Swift container test2: GET /keys/1bd3e4429a441fd7546efdfa1bc7c41333d548b0a1ecb5dea3fd1f9ef16c205f
rclone: 2019/12/07 12:40:07 DEBUG : 1bd3e4429a441fd7546efdfa1bc7c41333d548b0a1ecb5dea3fd1f9ef16c205f: Get request open error: try again after 2019-12-07T12:50:07.317400358+01:00 (9m59.999921857s)
Load(<key/1bd3e4429a>, 0, 0) returned error, retrying after 720.254544ms: <key/1bd3e4429a> does not exist

Similar behavior with other restic commands, like backup etc.

If you wait long enough and redo the command, restic works fine. However, the issue occurs with

• key files
• config file
• lock files

Therefore you might have to repeat and wait quite often before the requested operation is performed.

Another issue is, that the above files are not cached and therefore once you manage to get these files "warm" in the backend, you can do your operations. But if they get "cold" again, you again come in the original mentioned issue.

What backend/server/service did you use to store the repository?

rclone to access OVH via swift.
The rclone config is directly as provided by OVH.
test2 is a bucket in OVH Cloud Archive

Expected behavior

• restic should wait until the data is ready to access. Ideally giving a hint that it is waiting.
• restic should cache config file, key files and lock files.

Actual behavior

• restic stops without performing the requested observation when data is not yet ready to access
• config file, key files and lock files are not cached.

Steps to reproduce the behavior

• create an bucket in OVH Cloud Archive
• run restic init on this bucket
• wait some time to let the data become "cold"
• perform the commands given above

Do you have any idea what may have caused this?

restic is not prepared to using a "cold" backend.

Do you have an idea how to solve the issue?

1. I would suggest adding an option which allows restic to wait even for a real long time if it doesn't receive the data for a backend
2. Even better would be to get and use the information how long we have to wait. Then just wait long enough and display to the user that you are waiting.
3. Another improvement would be to use the waiting time an try to get other files you need from the backend. Ideally restic should try to start the warmup-process for as many files as possible.
4. Implement caching for key files, the config file and lock files. I think this involves following steps:

• Optionally organize caches by repo string instead of repo ID to make caching of key files and config files possible
• Add key files, config files and lock files to the cache implementation in internal/cache
• Check which commands need improvement to use the cache information

I would like to work on 1. and 4. and appreciate any help!

Did restic help you today? Did it make you happy in any way?

I do my daily backups with restic and like it very much! I especially like the possibility to directly backup to a cloud storage. Before I used other backup tools to backup to a local disc and sync the backup to a cloud storage. This solution failed badly once I had a problem with my USB hub which destroyed my local disc backup (and consequently my cloud storage copy)
Moreover using restic backup --stdin for DB backups is just great and makes me very happy 😄