The title is a little provocative, but hear me out. My argument is that in most situations, resorting to restoring data from backups means the project or business is already in an untenable position.
Suppose Kym from the Accounts department overwrites a document and asks for the file to be restored from backups. That’s a legitimate use of backups and assuming there’s no shadow copy version of that document available, then backups are the best and only solution.
Now suppose you’re working in a transactional environment such as an online store, inventory or accounting system. Resorting to backups in an incident is unacceptable and would mean that any RTO (how much time can be lost due to a disruption) or RPO (how much data can be lost due to a disruption) greater than zero would likely be violated. Granted, some businesses might accept that, most wouldn’t.
I’d suggest to put 99% of the effort into BCP (business continuity planning) such that these incidents don’t occur in the first place. For example, using clustered databases across multiple servers, hardening the application that interacts with the database, adding controls to manage access to that application, adding logs or journals to track transactions to allow for re-building (scripted, of course) any missing transactions between the start and end of the incident, and restricting what commands can be sent to the DB from any user or location.
The examples for mitigation in the above paragraph aren’t exhaustive, but they highlight my point. Resorting to backups in a transactional environment is untenable.
We need backups and they make us feel warm and safe. I use them, and I insist they’re checked and tested and confirmed to work as intended. The key is to ask and answer the questions:
1. What are the RTO (recovery time objective) and the RPO (recovery point objective – how much data can be lost) and does/can the backup solution comply with this?
2. If not, does the data/business owner accept that risk?
