Pārliecināties, ka dublējumi tiek atjaunoti

Kad izmantot

Quarterly, or after any change to the backup system itself (new storage target, new tool, new key holder). Not during an actual outage — under pressure you restore production, not run a drill; that is tech.website-down / agents.incident-response. Not for checking that a backup job ran — that is a daily watch, part of tech.security-audit.

Pirms sāc

• The backup inventory is current: what is backed up, where, how often, retention.
• Key holders are known by name for every encrypted backup.
• A non-production place to restore into exists (spare VM, container, scratch folder) — never the live system.
• If the company has stated recovery targets, they are written down; if not, this drill produces the first

Ko izpilde pieprasa2

Ceļš7 soļi

1. S1

   Pick the targetaģents

   Choose one system from the inventory — rotate so a different one is drilled each quarter; prefer one that has never been restored. Note the newest backup and its timestamp.

   Izdarīts, kad the target, the backup file/job id and its timestamp are written in the drill log.

2. S2

   Approve the planīpašnieksvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S2 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

   One paragraph: what will be restored, into where, what will be checked, who is on call if something breaks.

   Izdarīts, kad the owner has approved the named target and place.

3. S3

   Restore into isolationaģents

   Restore the chosen backup into the scratch environment. Nothing points at production; no live hostname, no live database connection.

   Izdarīts, kad the restored copy starts or opens, and no connection string in it points at production.

   ⛔ A restore that reuses live credentials or a live hostname can overwrite or corrupt production — rename everything before first start.

4. S4

   Verify the dataaģents

   Compare against the source: file counts and total size, database row counts on the main tables, checksums on a sample, open one real document end to end. Check the data age — is it the backup you think it is?

   Izdarīts, kad each check has a recorded number from both sides, and "pass" or the exact mismatch.

5. S5

   Time it and find the gapsaģents

   Record how long the restore took and how old the data was. Note anything that made it slower or harder: a key that had to be hunted for, a credential that had expired, a missing instruction.

   Izdarīts, kad restore time and data age are in the log, with every obstacle listed.

6. S6

   Decide on the resultīpašnieksvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S6 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

   Present pass/fail, the numbers, the obstacles. The owner accepts the drill or assigns fixes with owners and dates.

   Izdarīts, kad the decision is recorded — accepted, or each gap has an owner and a due date.

7. S7

   Record and scheduleaģents

   Write the drill log entry; add fix tasks where decided; set the next drill date a quarter out; tear down the restored copy (or keep it, if the owner wants it kept).

   Izdarīts, kad the log entry exists, tasks are created, the next date is in the calendar, and the scratch environment is cleaned or marked.

Pārbaudes — kā zinām, ka izdevās

• The restored copy was opened and read, not merely unpacked — a file count alone is not a check.
• Data age of the restored copy matches the newest backup's timestamp (read it from the restored data, not
• No production host, address or credential was used during the restore.
• Restore time and data age are written as numbers, next to any target the company has set.

Ja noiet greizi

Ko atstāj katrs solis

1. S1the target, the backup file/job id and its timestamp are written in the drill log.
2. S2the owner has approved the named target and place.
3. S3the restored copy starts or opens, and no connection string in it points at production.
4. S4each check has a recorded number from both sides, and "pass" or the exact mismatch.
5. S5restore time and data age are in the log, with every obstacle listed.
6. S6the decision is recorded — accepted, or each gap has an owner and a due date.
7. S7the log entry exists, tasks are created, the next date is in the calendar, and the scratch environment is cleaned or marked.

Ko saglabāt

Drill log entry (target, backup id, timestamp) · restore output · S4 comparison numbers · restore time and data age · obstacles list · S6 decision with who and when · task ids for any fixes.

Kā šī procedūra uzlabojas

After every 4 runs (a year) ask: did every system get drilled at least once, or does the rotation skip the hard ones? Did any obstacle in S5 repeat across drills without a fix closing it? Are the recorded restore times still within what the owner would accept in a real outage? A new version changes the step that let the gap persist, and says so in its change note.