// Connect · data protection & restart
Backup and disaster recovery
Taking backups is the duty. Getting data back is the skill. We build copies an attacker cannot delete alongside everything else — and rehearse the way back before it is needed.
// The actual point
Nobody needs a backup. Everybody needs a restore.
In almost every business we take over, some kind of backup is running. Green ticks in the log, tapes or disks in a cupboard, a line in a contract. The awkward question only arrives on the day itself: how long until the order system takes orders again?
What often turns up then is that files were saved but not the configuration that turns an empty server back into a working system. Or that the backup sat on the same storage as the data, and the attacker took both.
So we reverse the order. We ask first how long each business process can survive without IT, then build the backup so that it meets that requirement. What counts in the end is the time until the first order can be fulfilled again.
// 3-2-1
Three copies, two media, one off site
A proven split that no single event can strike all at once.
The fast copy in the building
For the everyday case: a file deleted by mistake, a document overwritten, a failed drive. This copy is within reach and comes back in minutes.
The copy off site
For the case where the site itself is affected — water, fire, break-in. It lives in a different environment with credentials of its own.
The copy nobody deletes
For an attack: written once, then unalterable for a set period. Even stolen administrator rights lead nowhere against it.
// Procedure
From concept to a restart you can evidence
The last step is the important one — and the one most backup concepts leave out.
What may be missing, and for how long
We go through the business processes and set which systems come back first and how much data loss is bearable at which point.
Set up the backup
Automated runs, separate credentials for the backup environment, unalterable copies and a location outside the building.
Practise getting it back
Restoring individual files and whole systems into a separated environment — with a written result rather than a verbal assurance.
Stay with it
Failed runs report themselves, new systems get taken into scope, and the test is repeated rather than ticked off once.
// On the day
The day it counts is a poor time to start thinking
On the day of an outage it is not the technology that decides, it is the preparation. Whoever knows in advance who to call and in which order systems return loses hours. Whoever works that out on the spot loses days.
CybersecuritySeparate affected systems, establish the scope, reach the decision makers — from a fixed list, not from memory.
The agreed core systems come back; everything else waits, deliberately.
Remaining services, follow-up work and the question of how the incident got in.
Whatever was missing goes into the plan. Every real event improves the next one.
// Self-check
Questions your emergency plan should answer
If you hesitate twice here, an outside look is worth the time.
-
When did you last restore something?
Not checked — actually restored, with a date and a result against it.
-
Who may decide on the day?
For instance about taking systems off the network and pausing operations.
-
Does the backup work without your own network?
If the backup can only be reached from inside your network, it will not help you when the site itself is damaged.
-
Are credentials available offline?
Passwords in an encrypted vault on the affected system are of little use on the day.
-
Do staff know what to do?
A single instruction sheet at the workplace stops everybody calling the same number at once.
// Questions about backup & recovery
What businesses ask about protecting their data
01 What does the 3-2-1 rule mean?
Three copies of your data, held on two different types of medium, one of them off site. The thinking behind it is simple: no single event — no fire, no failure, no encryption attack — should be able to reach every copy at once.
02 Is a backup enough protection against encryption attacks?
Only if the backup itself cannot be reached. Attackers now hunt for backups deliberately and delete them first. So we work with copies that cannot be altered once written, and with separate credentials for the backup environment.
03 Do you really test the restore?
Yes, on a schedule rather than when there happens to be time. We restore individual files, whole mailboxes and complete systems into a separated environment and record the result in writing. A backup that has never been restored is an assumption.
04 How quickly are we working again after an outage?
You help decide that, through the question of which systems have to come back first. We set that order together and build the backup to match. What is actually achievable is shown by the restore test, not by a promise in a quotation.
05 Do you back up data that already lives in the cloud?
Yes. A remote service is not a backup — content that is deleted or encrypted there is just as gone. So we pull copies of our own out of cloud services and store them outside that environment.
06 What belongs in an emergency plan?
Who decides on the day, who gets informed, in which order systems come back, and how work carries on without IT until it does. The plan deliberately exists on paper as well — on the day, the file store is often exactly the problem.
Related
When did you last get something back?
We look at the backup you have, restore from it as a trial and tell you how long a restart would really take with things as they stand today.