Note that restic check always checks for existence of the needed pack files and with version 0.12.0, it also verifies the size of the pack files - even if called without --read-data* (it doesn’t need to read the files in order to check the file size ). These tests effectively detect missing or truncated (or too large) pack files .
Personally, with the major cloud providers I would run check without reading any pack file at all (and thus fully trusting the cloud provider to properly keep the data) . If you are suspicious about your cloud provider, there is the possibility to run check --read-data-subset x% to randomly choose a subset of pack files which will be then checked by restic.
I would however run check --read-data for repos on a local HDD regularly.
@doscott and @alexweiss thanks for your suggestions. I was starting to come to similar conclusions that what I was proposing was an OVERKILL.
I haven’t quite worked out my strategy yet. Although I don’t have too much data is is CRITICAL to the company’s day to day operations and therefore the need to get BACK good data is important.
I’ll have a think about it further but very much appreciate your guys guidance and thoughts. A second repo with a different provider would be a good thing.
My server is with Rackspace so there is no ability for ‘local’ backups…although they do offer a ‘block storage’ facility but that would still be within the same region.
HO HUM!! Who would have thought backups needed so much thought.
Right. This makes running restic check --read-data dangerous because if you need to restore within the same month then they might suspend your account. Even restic prune could get you into trouble since repacking requires downloading data only to reupload it again.
I prefer Backblaze’s approach: you just pay $0.01 per GB of egress and you can decide what is worth running. You can run whatever you are willing to pay for.
Do you mean 1/7, 2/7, etc.? 1/5 means the repository will be fully read every 5 days, not every week. (Unless you are only running this on business days, or something like that.)
Yes, this would count towards egress. If you are on Wasabi then this approach would get your account suspended in probably under two weeks since you are doing more egress than you have total storage within a month.
This would be fine to run on B2, as long as you’re willing to pay the egress fees for it. Instead you could consider running 1/28, 2/28 etc. on days 1-28 of each month (to account for February). This will check all data in the repository every month. This is still not a great idea on Wasabi, but on B2 it would accomplish roughly the same thing once per month and at about a 1/4 of the monthly egress fees.
@cdhowie Thanks very much for your considered response. Yes perhaps once a month for overall coverage of the repo during check would be enough…although given the enhancements in 0.12.0 it may be that just check by itself daily is probably enough.
The worst thing about having ‘options’ is you want the one with the MOST belts and braces.
Currently I am continuing to have problems with Wasabi access using the API. Although their support are helpful I don’t think they are getting close to solving it. Given my timescales I may have to start on Backblaze b2.
Just a final note on here. Firstly many thanks for everyone’s comments and suggestions. Very helpful indeed.
My problems with connecting to Wasabi turned out to be a typo error in my shell script for which I’m embarrassed but relieved that it’s working.
I have for the moment decided to not use the -read-data-subset flag so restic is only checking meta data. I’ll periodically pull down random data till I feel completely at ease. Also I will probably set up a second repository on Backblaze b2.
). These tests effectively detect missing or truncated (or too large) pack files .