The backup passed. Has the restore been tested?

The backup dashboard is green. Now ask a different question: when was the last time someone recovered the data and checked that it worked?

A completed backup job and a successful recovery answer different questions. The first tells you about the backup process. The second tests whether the copy, credentials, tools, and recovery procedure work together.

Define what a successful restore must prove

A database starting is a useful first check. It may not be enough. Can the application read the expected records? Are the permissions intact? Did the recovery include the keys or external dependencies the service needs?

Write those checks before running the exercise. Otherwise it is easy to stop at the first healthy status and leave the important questions unanswered.

Use an isolated target and keep a record

A disposable recovery target lets you exercise the process without overwriting production. It still needs controls: restored data is another copy of sensitive data, with its own access and cleanup requirements.

Record the backup used, the scope restored, the checks performed, the elapsed time, and the result. Include failed attempts. If an expired credential caused the first attempt to fail, that is part of what the exercise discovered.

CIS Control 11 includes testing recovery. The useful operational habit is to make those tests repeatable and to relate their frequency and scope to the service’s recovery requirements.

Keep backup and restore permissions separate

Writing a backup and restoring one expose different risks. A restore reads data back out and may replace an existing system. Someone responsible for routine backup jobs does not necessarily need permission to do either.

In Moncho, dedicated tenants can manage cluster backup and recovery through the portal. Backup-write and restore permissions are separate, and the normal platform-staff permission path excludes tenant restores. Tenant backup credentials are scoped to the tenant’s object-store bucket.

State exactly what the drill covers

Moncho runs a daily restore-to-disposable-target drill for its management database backup path and records the outcome in a tamper-evident ledger. It also provides dedicated-tenant backup and restore through Velero.

Those statements should not be combined into a claim that every tenant workload is restored and application-tested every day. A management database drill tests that path. A tenant application recovery needs checks appropriate to its own data and dependencies.

A full quarterly disaster exercise remains planned. A documented recovery path or an individual successful restore is not the same as rehearsing the loss of the whole service. Backup location and immutability also need to be confirmed for the deployment being evaluated.

Bring a recovery scenario to the evaluation

When reviewing Moncho, name the service you need back and the failure you want to recover from. Ask which parts the existing drill covers, which need a separate rehearsal, and who owns each step.

The answer should leave you with a dated test you can inspect and a clear list of what remains untested.