Trust / Backups and recovery
A backup nobody has restored is a hope
Encrypted backups, a restore script, a weekly verification that the restore actually works, and dead-man alarms if either stops happening.
The final check in the drill is deliberately human: read a real customer’s name on screen. A restore can complete perfectly and leave every encrypted field as unreadable ciphertext.
Ask for the DR positionHow do you know your backups work?
Because we restore them weekly and time it. The drill produces a measured recovery time rather than an estimate, and its last step is a person reading a decrypted customer name — a check that a row count cannot fake and that catches the specific failure where the data restores but the keys do not.
Verified, not assumed
The drill, and why its last step is manual
- 01
Backups are encrypted
A backup is a complete copy of the most sensitive data you hold. Encrypting the live database and shipping plaintext backups is a common and serious inconsistency.
- 02
The restore is scripted
Recovery follows a written script rather than the memory of whoever is awake. An untested runbook is a document, not a capability.
- 03
Verification runs weekly
The restore is actually performed on a schedule, and the drill is timed. The number it produces is the recovery time objective every insurer and enterprise buyer asks for.
- 04
A human reads a real name
The mandatory final check. A restore can succeed completely and leave encrypted fields as ciphertext — invisible to a row count, obvious the moment somebody opens one claim.
- 05
Dead-man alarms cover silence
If a scheduled backup or a scheduled verification stops happening, an alarm fires. The dangerous failure is not a job that errors loudly; it is one that quietly stops running.
The honest DR position
Where we are strong and where we are not
This is the section most vendors blur. We would rather you know the weak spot now than discover it during an incident, because that is the moment it becomes a relationship problem as well as an outage.
Backup encryption
Encrypted, consistent with live-data handling
Restore procedure
Scripted and documented
Restore verification
Performed weekly, timed, with a human decryption check
Recovery time objective
A measured figure from the drill, not an estimate — ask us for the current number
Scheduled-job monitoring
Dead-man alarms on both the backup and the verification
Automated failover
Not implemented. Recovery is a restore, and a restore takes time
Multi-region redundancy
Not implemented. If your requirement is hot standby, we are not there yet
We do not have automated failover
Saying so costs us deals with buyers who need hot standby, and we would rather lose those than win them and disappoint somebody during their worst week.
Recovery is a restore
There is no automatic cutover to a standby environment. Recovery means executing the restore script, and the recovery time is the drill figure — real, measured, and longer than a failover.
Single region today
A regional infrastructure failure is a restore event, not a transparent redirection. If a multi-region requirement is firm, ask early and we will tell you where it sits on the roadmap.
The drill number is the number
We will give you the measured recovery time rather than an aspirational one. It is not the fastest figure in the category, and it is the one we can substantiate.