3 ms·
Some more context. > - a CLI verification option that will test a given % of your backup objects (at random) every time it's run, to give you opportunistic ran
by hashhar 4y ago
Some more context.
> - a CLI verification option that will test a given % of your backup objects (at random) every time it's run, to give you opportunistic random verification to try find issues.
FWIW Restic also supports this - see restic check --read-data-subset (https://restic.readthedocs.io/en/stable/045_working_with_repos.html#checking-integrity-and-consistency https://restic.readthedocs.io/en/stable/045_working_with_rep...)
Also Restic doesn't have any problems with buckets with deletions disallowed as long as you allow them for just the `locks` directory. A policy I used for one of my targets looked like:
{
"Statement": [
{
"Sid": "AllowAdditions",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::BUCKETNAME"
},
{
"Sid": "AllowDeleteLocks",
"Effect": "Allow",
"Action": "s3:DeleteObject",
"Resource": "arn:aws:s3:::BUCKETNAME/locks/*"
}
]
}
And it even works with buckets with object locking enabled since >= 0.13.
- aborsy 4y agoI guess if you comment out the delete disallowing the action on lock, you can prune the repository once in a while without reindexing? Then pruning could be done once every few months. The egress fees could be high though.