A backup is a restore you have not tried yet.
We design the backups, then we restore from them while you watch. The runbook is written from what happened during that test, not from the vendor's datasheet. And we decide what you can afford to lose before we decide what to buy.
Why it matters
The backups run every night and nobody has ever restored one. That is the common case, and it is the one that fails at the worst moment. So the deliverable includes an actual restore, not a green tick in a console.
The other failure is ransomware reaching the backups through the same domain admin account that runs everything else. One copy has to be somewhere it cannot follow.
What it covers
- What gets protected
- Servers and virtual machines, databases, domain controllers, Microsoft 365 and Entra ID data, and network device configurations, and where a site has them, PLC and HMI project files and historian databases. Golden images for workstations where a rebuild has to be fast.
- The recovery numbers
- Recovery point (how much data you can lose) and recovery time (how long you can be down), per system, agreed with the people who run each service. The design follows from those two numbers.
- A copy nothing can reach
- 3-2-1-1-0 as the target: three copies, two media, one off-site, one immutable or air-gapped, zero errors on a verified restore. Immutable object-lock or WORM storage, or a hardened offline copy, with backup credentials kept off the domain.
- The order things come back in
- Bare-metal recovery, application-consistent snapshots, retention on a grandfather-father-son schedule, and a recovery order that respects the dependencies between them.
How it runs
Agree the numbers
Recovery point and recovery time per system, set with the people who run it, not assumed. Decide what you can lose before you decide what to buy.
Design
The architecture that meets those numbers, including the immutable or air-gapped copy and where the credentials and keys live.
Restore, and watch
We restore from the design while you watch, and time it against the recovery-time target. The first restore is a deliverable, not a promise.
Write the runbook
The recovery runbook, written from what actually happened during that restore: the order, the dependencies, and where the licences and keys are.
A page of what you are handed
ARTA CYBER
Representative deliverable — site and figures redacted.
RPO / RTO table — excerpt
| System | RPO (data you can lose) | RTO (time you can be down) | Method | Immutable copy |
|---|---|---|---|---|
| Domain controllers (2) | 24 h | 2 h | System-state backup, plus a written forest recovery procedure | Daily, object-lock |
| Finance database (SQL Server) | 15 min | 4 h | Transaction-log backups and a nightly full, application-consistent | Daily, object-lock |
| File, print and application VMs | 24 h | 8 h | Hypervisor-level image backup | Weekly, air-gapped |
| Microsoft 365 mail and files | 24 h | 4 h per mailbox or site | Separate tenant backup; native retention is not treated as a backup | Daily, credentials held outside the tenant |
| Firewall / switch configs | On change | 1 h | Automated config backup on commit | Daily, off-domain repo |
What you are left holding
- Backup inventory: what is protected, how, how often, where.
- RPO and RTO table per system, agreed with operations.
- Architecture drawing.
- Retention schedule.
- Restore-test plan and the first test's results.
- Recovery runbook with recovery order and dependencies.
- Credential and key custody note.
Worked to
- NIST CSF 2.0 (Recover)
- IEC 62443-2-1
Questions we are asked first
Does designing this touch production?
The design work is read-only. The restore test runs against a recovered copy on separate hardware or an isolated network, never by overwriting a running server, and any part that needs a production window is booked as one.
Can ransomware reach the backups?
That is exactly what the immutable or air-gapped copy and the off-domain backup credentials are for. One copy is designed so that a domain-admin compromise cannot delete or encrypt it.
Can you recover Active Directory, or only the servers joined to it?
Both, and the order matters. Domain controllers come back first, from a backup taken before the compromise, and the runbook records how to check that before you rely on it, because restoring a directory that still holds an attacker's accounts is not a recovery. Where a site has PLCs, the same test compares the offline project file against the running program.
Do you prove the recovery time, or just claim it?
We time the restore during the test and record it against the target you agreed. If it does not meet the number, the design changes until it does.
Related work
Tell us what is bothering you.
An email is enough to start with. A scoping call is free and there is nothing to commit to, and where we are not the right people we will say so and point you at someone who is.
A first call about one site. No charge, and nothing to commit to.
Our named next step: we come to one site and hand you an assessment you can act on.