Recovery in hours, not weeks
The recovery plan states what to restore, in what order and from which copy. Nobody improvises on the day of the incident.
Your data protected, your business never at a standstill
Companies almost never lose their data through a dramatic event. They lose it because a disk failed, because a folder was deleted by mistake on a Friday evening, or because the backup had been running for eight months onto a drive that had stopped writing anything.
So the question is not whether you have a backup, but how long it has been since its restoration was last tested. A backup that has never been restored is only an assumption.
We put a complete arrangement in place: automatic backup, offsite copy, encryption, periodic restore tests and a written recovery plan stating what to do, in what order and by whom.
None of them is rare. We meet at least one of them every quarter.
A hard drive has a limited lifespan. When it stops, it takes everything it held with it, with no warning and no simple recovery.
A deleted folder, an overwritten file, a database emptied by a wrong click. By far the most frequent cause.
Your files are encrypted and a ransom is demanded. Without an offline or offsite copy, the company has no fallback position.
Fire, water damage, server theft. A backup stored next to the machine it protects disappears along with it.
The recovery plan states what to restore, in what order and from which copy. Nobody improvises on the day of the incident.
Every run is checked and you are alerted on failure. No more backups silently stopped for months.
Offsite copies are isolated and immutable for the retention period. An attacker cannot encrypt them.
A file overwritten on Tuesday can be recovered as it was on Monday, without mounting a full restore operation.
A coherent arrangement, not just software installed on a server.
These four parameters drive both the cost and the level of protection.
We identify what exists, where it is stored and what genuinely stops the company if it disappears. Not everything carries the same value.
Step 1How much data can you afford to lose, and how long can you stay down? Those two answers drive the whole architecture.
Step 2Agent installation, job configuration, encryption, offsite replication and alert setup.
Step 3We genuinely restore data into an isolated environment to confirm the chain works end to end.
Step 4Writing the plan, assigning roles, then running a drill with your teams so the procedure is known before it is needed.
Step 5A production folder covering several years, deleted by mistake at the end of the day.
Targeted restore from the previous night's backup, in under an hour, without touching the rest of the server.
The main server no longer boots, the motherboard is dead and a replacement takes several days.
Services brought back up on standby hardware from the backups, activity resumed the same day.
Shared files are encrypted and a ransom note appears on the workstations.
Network isolated, restoration from the immutable offsite copy, no ransom paid.
A backup that has never been restored is not a backup: it is an intention.
It depends on three points: is it automatic, does an offsite copy exist, and has it ever been restored successfully? If a single answer is no, the arrangement is fragile.
Full backups run outside working hours. During the day only changes are transferred, which stays imperceptible to users.
In hosting we select with you, according to your location and confidentiality requirements. Data is encrypted before it leaves your site.
Four times a year in a standard setup, with a written report each time. A test can also be added after any significant change to the system.
The order of restoration, everyone's role, who to contact, target timeframes and detailed procedures. It fits in a few pages, readable under pressure.
We can start with a review of what exists: what is backed up, what is not, and what could actually be recovered.