S3 and the name 'locks'

Restic version 14, 15, 16, 17 - the ones I knew

My S3 provider is Contabo
From time to time the object with the prefix “locks” gets corrupted.
Neither Contabo’s website, nor AWS CLI, nor Cyberduck can access the object.
Needless to say, restic will not be able to work with this object either.
The best you get is

<Error>
<Code>NoSuchKey</Code>
<Message/>
<BucketName>xxxx</BucketName>
<RequestId>tx000005b951fe4c86ecbbb-00666ab86a-102645d-default</RequestId>
<HostId>102645d-default-default</HostId>
</Error>

For sure I am able to use the old data and specify --no-lock for restore.
And for sure I will create a new prefix for future backups - until Contabo stops my access to the object at the prefix ‘locks’ again.

I am very happy with the developers and the documentation of restic:

  • Creating an new Ubuntu VM,
  • installing GO,
  • cloning restic,
  • Edit ‘internal\backend\layout\layout_default.go’,
  • Change the variable defaultLayoutPaths - ‘locks’ to ‘lock2’,
  • compiling,
  • took less than half an hour.

I would be very happy if the S3 prefix could be set externally, without editing and compiling the code. This would allow me to keep my data even if the object in the S3 prefix ‘locks’ gets corrupted.

I know that the meaning of a lock object is critical to the integrity of the data. I think I know what I am doing :slight_smile:

Cheers
Daniel

I think you do understand that it is unlikely going to happen. As what for? Do development, testing and maintenance for one user using some niche provider offering buggy S3 storage…

IMO I would start with seeking answers from Contabo and if they are unable to fix it I would seriously consider changing provider. Personally I would not hesitate especially that their pricing is far from competitive (12 USD per TB/month). I do not want to advertise here but you can find reliable and working S3 storage for half of it.

If it happens with lock file (which you can notice pretty much immediately) I would assume that it also can happen with any other file leading to different errors you can only notice much later. Not worth to trust such storage with precious backup data:)

Also nice you have found DIY solution but I do not think it is worth to be included in general restic release.

Let’s see what others think.

2 Likes

From a developer’s point of view: You are absolutely right.

Talking to Contabo and explaining what was going on took a lot more time than building a special restic version myself.
My guess is that Contabo’s S3 is reasonably reliable for everything else, my scripts always restore everything after the backup, and do a binary comparison of the backup source and the resulting restore. This never throws an exception.
I have no problem with restic, but just wanted to ask for a favor.

S3 object store price comparison: Contabo is quite simple, you pay for storage size, thats it, no egress traffic, no ingress traffic, no connection time.
Yes, I hear people say that if you buy cheap, you buy twice. :slight_smile:

Thanks anyway.
Daniel

I don’t know anything about S3, never having used it, but this statement makes me think “ok, so try with some other S3 provider and see if they have the same problem”. And if they don’t, then the blame rests squarely with this particular one.

I would agree with the other person who said this is far too case-specific to be added to restic code.

1 Like

Let’s cut this discussion short: this won’t happen.

If the locks prefix becomes inaccessible, then open a support ticket with the provider and ask them to fix their service. Restic relies on the backend not randomly breaking.