Locking backups in an S3 bucket (Object Lock)

A backup that can be deleted can be deleted by the wrong person: ransomware that found the bucket's keys on the PC, or someone who should not. S3 Object Lock stops that. Each backup GBM AI writes to the bucket is locked for the number of days you choose. Until then nobody can change or delete its files: not GBM AI, not a program that took over the PC, and in compliance mode not even the bucket's owner. Object Lock works with Amazon S3, Wasabi, MinIO and other providers that support it. Cloud destinations are part of Pro.

Before you start: a bucket with Object Lock#

Object Lock can only be turned on when a bucket is created. An existing bucket without it cannot be changed, so make a new one:

• Amazon S3: Create bucket ▸ Advanced settings ▸ Object Lock: Enable.
• Wasabi: Create bucket ▸ Enable Object Locking.
• MinIO: mc mb --with-lock myminio/my-backups.

Leave the bucket's own default retention off: GBM AI sets the lock on each backup itself, and a default retention would also lock the catalogue that changes on every run, keeping a billed copy of each until it ends. Object Lock also turns on versioning, which GBM AI handles for you (see below).

The keys in the S3 profile need, besides list, read, write and delete: s3:GetBucketObjectLockConfiguration, s3:PutObjectRetention, s3:GetObjectRetention, s3:ListBucketVersions and s3:DeleteObjectVersion. Never give them s3:BypassGovernanceRetention.

Turning it on in the wizard#

1. On the Where step choose Cloud (S3-compatible), then the profile and the new bucket.
2. Test destination says Reachable and writable · Object Lock on. If it says the bucket has no Object Lock, the bucket was made without it.
3. Tick Lock each backup in the bucket.
4. Lock mode:
   • Governance (the default): an administrator of the bucket with a special permission can still lift a lock, for example to clean up a test. Everyone else, GBM AI included, cannot.
   • Compliance: nobody can lift it, not the bucket's owner and not your provider's support, until the days have passed. Choose it when a rule says backups must not be deletable.
5. Locked for: 1 to 3650 days, counted from the start of each backup.

A second copy in a bucket has the same choice in its panel, counted from when each backup is copied. The copy's bucket needs Object Lock too.

Retention and locks#

• A backup stays until its lock ends, even when your retention would remove it sooner. Retention removes it at the first run after the lock ends.
• A chain is kept whole: an incremental that is still locked keeps the full backup it builds on.
• When retention removes a backup from a bucket with Object Lock, it removes every version of its files, so the space is really freed (a plain delete there would only hide the files and keep billing them).
• What is not locked: the job's catalogue (db/backup.db) and its gbm-ai.json at the top of the job's folder in the bucket. They change on every run, and restores never need them. Their earlier versions are removed after each run, so they do not pile up.

Things to know#

• A mirror job cannot be locked: it replaces its one backup on every run. Pick incremental, differential or full.
• A run that is cut short (the PC switched off, the app ended) can leave files in the bucket. When the job has a retention limit, a later run removes them once their lock has ended.
• Each finished backup folder holds a .gbmai-complete file, written last. A tool that copies the bucket elsewhere should take only folders that have it.

Troubleshooting#

E-DEST-010: The bucket has no Object Lock#

The job locks its backups, but the bucket was made without Object Lock. Create a bucket with Object Lock on and point the job at it (Edit ▸ Where), or turn the job's lock off.

"is locked until …" in the run log#

Retention reached a backup whose lock has not ended. Nothing is wrong: it is removed at the first run after that date.

Related articles#

• Backing up to S3-compatible cloud storage
• Keeping a second copy
• Retention