Backup restore testing

Backup restore testing is the exercise in which a company rebuilds data or an entire system from its copies, to check that the backup works on the day it has to restart. A backup that has never been restored is an assumption. June 2017, NotPetya: at A.P. Møller-Maersk, rebuilding the directory relied, according to the account published later, on a domain controller in Ghana that had stayed offline because of a power cut. Nobody had planned for that path. The cyber application now asks how often tests run, what they cover and when the last one took place. Restoring a random file says nothing about bringing back a hypervisor, an Active Directory domain or an enterprise resource planning (ERP) system. The underwriter wants to know whether a full system was restored, in an isolated environment, and how long it took against the stated recovery objective. He often asks for the write-up of the last exercise. Ransomware goes after backups first: the attacker finds the backup console, deletes or encrypts the copies, then sets off encryption in production. Hence the link with immutable and offline backups, which the test has to cover too. A failed restore changes the nature of the loss. Business interruption runs longer, data restoration costs climb, and the pressure to pay the ransom grows, which the market watches closely when it applies a ransomware-specific coinsurance. A practitioner's caveat: companies like to restore what restores easily. The test that matters covers the directory and identities, without which no restored server comes back up cleanly.