Azure SQL has been backing up the Kladde since day one, without you having done anything for it. Since lesson 3.6.3, Blob Storage has kept versions and deleted files. Key Vault keeps deleted secrets. So you have backups. Whether you can get data back with them, you only know once you've done it: What's the command called? How long does it take? Who's allowed to do it? What about the data written after the point in time? This lesson therefore has a sentence that belongs in every operations manual:
A backup whose restore has never been rehearsed is not a backup.
At the end of this lesson there's a runbook in the repository that does the rehearsal, measures it and cleans up. In lesson 3.10.8 you run it once more, against the finished Kladde.
RPO and RTO
Two numbers describe what a restore has to achieve:
- RPO (recovery point objective): How much data may be lost at most, measured in time? An RPO of 15 minutes means: After an incident, at most the changes of the last 15 minutes are missing.
- RTO (recovery time objective): How long may it take until the application is running again?
Both numbers are decisions, not measurements, and they cost money. An RPO of zero needs a second database that's written to continuously; an RTO of minutes needs a ready replacement environment. For the Kladde of a small office, other numbers are honest:
| Data | Target RPO | Target RTO | Reason |
|---|---|---|---|
Database kladde |
15 minutes | 4 hours | appointments and contacts are people's work; half a workday without the Kladde is annoying, but not damaging |
Raw data in tenders-raw |
1 day | 1 day | TED is the source; what's missing, the next import fetches |
Offers in offers |
0 | 1 day | a lost offer can't be fetched again; versions make every change reversible |
| Secrets in Key Vault | 0 | 1 hour | without the signing key, no booking links |
Whether the numbers hold is shown by the drill at the end of the lesson.