The hardware and software underneath your backup policy
Backup targets, repositories and software sized for the restore time you actually need — because a backup that takes three days to restore is a policy document, not a recovery.
Backup infrastructure, end to end
Repository design
Disk targets sized for your retention and your restore window, with the throughput to actually deliver it under load.
Immutability
Hardened or immutable repositories so backups survive ransomware that reaches an administrator account. Without this the rest is decoration.
Offsite copy
A second copy on a second site, a cloud target, or both, so a fire or a flood is not also a data loss event.
Backup software
Veeam where it fits, native tooling where it does not, licensed correctly for the workload count.
Restore testing
Scheduled test restores with the results recorded. An untested backup is an assumption.
Reporting
Success, failure and duration reported to a person, with failures chased rather than filed.
Restore first, capacity second
Almost every backup estate we inherit was sized on how much data there is, and never on how long a restore would take.
1. Agree the objectives
How much data you can afford to lose, and how long you can afford to be down. Per system, not one number for everything.
2. Work backwards
Those two numbers determine backup frequency, repository throughput and where the offsite copy has to live. Capacity falls out of that, not the other way round.
3. Build
Repositories, immutability, offsite copy and jobs configured, with the throughput verified under load.
4. Test and report
Restores tested on a schedule, results documented, and the evidence produced in the format an auditor will ask for.
Common questions
We already back up. Why would we change anything?
Usually because nobody has tested a restore, or because every copy is reachable from the same administrator account that ransomware would compromise first. Both are common and both are fixable.
Is a snapshot a backup?
No. A snapshot on the same array does not survive the array, the site, or an attacker with storage access. It is fast recovery, and it belongs alongside a backup rather than instead of one.
Cloud or a second site?
Whichever meets the recovery objective at sensible cost. Often both: fast local copy for everyday restores, offsite copy for the bad day. See disaster recovery.
Does this produce audit evidence?
Yes. Backup success, retention and tested restores are controls in ISO 27001, PCI DSS and SOC 2. Our compliance team packages the evidence.
Tell us how long you could be down.
That single number, per system, determines everything else. Send it with a data volume and we will design against it.
02 3537 5791