Backup and recovery
By Redaktion techport.ai, IT-Beratung · Last updated on
Almost every company has a backup. Considerably fewer have a tested recovery. The difference shows exactly once, and then it costs weeks. Backups can be incomplete, they can sit on the same system that was encrypted, they can be reachable with the same credentials the attacker stole, and they can be technically flawless and still hold the wrong state.
Recovery is the part that counts. Everything else is preparation for it.
How you notice it
- The last full recovery was more than a year ago or has never happened.
- The backup is reachable over the same network and with the same accounts as the production systems.
- It is unclear how long a full recovery would take.
- New systems went live without anyone adjusting the backup.
Why this happens
Backup is set up and runs, and as long as the success message arrives everything looks fine. That message, however, only says that data was written, not that it is complete, consistent and restorable. A real test costs time and an environment in which you can restore without disturbing operations. Both are scarce in daily work, which is why the test gets postponed, often for years.
How we go about it
- Derive the requirements from the business. We determine per system how much data loss is tolerable and how quickly it has to be available again. Only those two figures decide the frequency, retention and technology of the backup.
- Establish separation and immutability. We ensure that at least one copy sits outside the production network with its own credentials, and that one version cannot be altered or deleted for a defined period. That is exactly what attacks fail on.
- Check completeness. We reconcile the backup against the system list, including configurations, directory service, virtual environments and systems operated externally. Cloud services generally back up their infrastructure, not your content.
- Test recovery and document it. We restore regularly in a separate environment, measure the time required and document the result. That documentation is the evidence insurers, customers and auditors ask for.
What you gain
- Certainty that recovery works, rather than the assumption.
- A solid figure for the duration that feeds into emergency planning.
- Protection against the most common emergency, in which backups are attacked deliberately.
From our projects
In the first recovery test, at least one component is regularly missing that nobody had on the list. Most frequently these are network device configurations, certificates, licence keys and the systems needed to manage the backup itself. If that management exists only inside the affected environment, recovery is blocked before it starts. The second reliable finding concerns cloud services: many companies assume the provider backs up their content. For the availability of the platform that is usually true, for accidentally deleted or encrypted content frequently not, or only for a short window.
Häufige Fragen
How many copies do we need?
A proven rule is to keep at least three copies of the data on at least two different media types, one of them off site and one that is immutable or physically separated. More important than the exact number is that one copy cannot be reached with the credentials of the production environment.
How long do we have to keep backups?
Backups serve recovery, not archiving, and a few weeks to months is usual. Retention obligations under commercial and tax law are met through archiving, not through backup. That separation matters, because otherwise either deadlines get breached or backups grow over years without anyone still being able to restore them.
Let us talk about Backup and recovery
In a thirty minute first call we work out where your biggest lever sits and whether we are the right people for it.
Further reading
Back to the field Security and Resilience