How to use
Quarterly, one hypervisor cluster at a time, with the machine inventory open beside the backup catalogue. Settle the four inventory items first — one list that matches the hypervisor, a named protection method per machine, snapshot-only counted as a gap, and a copy that is off the array. Nothing else in the review means very much until those four agree.
Two items decide the review. One is that a complete machine has been restored onto hardware that is not its source host, with a date against it. The other is that the recovery order starts with the infrastructure the hypervisor itself needs, rather than with the first guest somebody remembers.
Where the numbers come from
The machine count comes from the hypervisor, not from the inventory spreadsheet, because the difference between the two is the finding. Protection method comes from the backup catalogue’s record of what it last wrote for that machine, and the second copy is confirmed by looking at the destination rather than at a job’s exit status.
Snapshot consumption and overflow behaviour are read from the storage layer. Two captures in this course fix the shape of it. The first destroys the single device an origin and its snapshot both live on:
$ vgs; lvsSimulating permanent loss of the underlying device:
re-attached the same (now destroyed) backing store as /dev/loop5
--- what survived? ---
vgs:
lvs:The second replicated a snapshot to a pool on a different device, then destroyed the production pool:
$ zpool import, then a read of the 09:00 snapshot, then a listing of the independent backup pool--- zpool import (can ZFS find anything to import?) ---
no pools available to import
--- can the 09:00 snapshot be reached? ---
cannot open 'rbdrprod': dataset does not exist
--- what the INDEPENDENT backup pool still holds ---
NAME USED REFER
rbdrbkp 100M 24K
rbdrbkp/ledger 100M 50.1M
rbdrbkp/ledger@0900 50.0M 50.1M
rbdrbkp/ledger@0930 0B 50.1MThe mechanism in both captures is the same one. The independence is what differs, and it is the only property the off-the-array item is asking about.
Restore duration is measured, not estimated: from the moment the procedure starts to the moment a request completes against the recovered machine.
Access this needs
Read access to the hypervisor inventory and to the backup catalogue, and read access to the storage layer under both — the reviewer has to see which array a datastore was carved from, and that is frequently held by another team.
Enough spare capacity on a host that is not the source host to restore one complete machine, plus an isolated network segment to attach it to. That host and that segment are the review; without them most items degrade into reading configuration, which is the substitution this checklist exists to prevent.
Credentials for one machine’s service, so the post-restore request can be completed as the application rather than as an administrator, and contact with whoever holds the licence keys and the directory join procedure.
What the review produces
A dated record naming the reviewer, the machine count from the hypervisor against the count in the inventory, the machines protected only by a snapshot, and the machines with no application-consistent capture together with the recovery step each one implies.
Attach the restore record: date, machine, target host, measured duration, the request that was completed, and every place the written procedure turned out to be wrong. Those corrections are the value of running it — a rehearsal that produced none has usually tested something easier than a recovery.
Attach the recovery order with the hypervisor’s own dependencies at the top, and name anything in it that depends on something scheduled later.
Sign-off
- Reviewer: ____________ Date: ____________
- Virtualisation owner: ____________ Date: ____________
- Service owner: ____________ Date: ____________
Every critical item must pass. A failing critical item is a blocker rather than a note for next quarter: record the disposition of every item that did not pass, and the name of whoever accepted the residual risk.