The assumption that gets tested exactly once
Nearly every business believes it is backed up. A meaningful share of them are wrong, and they find out on the worst possible day.
The common failure modes are boring and consistent. The backup job has been failing silently for eight months because nobody reads the report. The backup includes the file server but not the database, which is open and locked during the backup window. The only copy sits on a drive plugged into the server it protects, so ransomware encrypted it too. The offsite copy exists but restoring 4TB over the available upstream bandwidth would take eleven days.
All of these are discoverable in advance. None of them are discoverable if nobody looks.
How we build it
Image based, not file based. We back up the whole system, not selected folders. That means a failed server can be recovered as a complete working machine rather than reassembled from files onto a fresh operating system install while your staff waits.
Three copies, two media, one offsite. A local appliance for fast recovery, replication to a geographically separate data center for site loss, and retention configured to your actual requirements rather than a default.
Immutable. This is the part that matters against ransomware. Modern attackers specifically hunt for and destroy backups before they encrypt anything, because that is what forces payment. Immutable storage means a backup, once written, cannot be modified or deleted for its retention period by anyone, including someone holding full administrator credentials. If your backups can be deleted from your network, assume they will be.
Microsoft 365 included. Cloud data needs backing up too. Microsoft’s retention is short and built for accidental deletion, not for a departing employee wiping a mailbox or a ransomware event propagating through OneDrive sync. We back up Exchange Online, SharePoint, OneDrive and Teams separately. See cloud solutions for the wider tenant picture.
Objectives, agreed in advance
Two numbers govern every recovery decision, and both are business decisions rather than technical ones.
Recovery point objective is how much data you can afford to lose, which determines how often backups run. Hourly snapshots cost more than nightly ones. For a busy order entry system, losing a day of transactions may be unacceptable. For an archive share, it may be entirely fine.
Recovery time objective is how long you can afford to be down, which determines the recovery method. Restoring from offsite is cheapest and slowest. Spinning a failed server up directly on a local appliance is fastest and requires hardware onsite.
We set these per system with you, because paying for one hour recovery on systems nobody would miss for a week is a waste, and discovering that your critical system was in the cheap tier is a lot worse.
Testing, because the report is not the proof
Backup software reports success when the job completed. It does not report that the data inside is consistent, that the database will actually mount, or that the recovery documentation still matches reality after last year’s server replacement.
We run scheduled restore tests. Files, applications and full system recoveries into an isolated environment, verified as functional, documented in a report you receive. When something fails a test, we fix it while it is a scheduling inconvenience rather than a crisis.
Once a year we recommend a full exercise with your leadership team, walking through an actual scenario and timing it. It is consistently the most useful hour our clients spend on this subject, because it surfaces the non technical gaps: nobody knows who calls the insurer, the emergency contact list is on the file server that is down, and the person who knows the phone system password is on vacation.
Ransomware specifically
Ransomware recovery is different from hardware failure recovery, and the difference is that you cannot trust anything.
Our playbooks assume the attacker had time inside the network before encrypting. That means containing and isolating before restoring, verifying that backups predate the initial compromise rather than just the encryption event, rebuilding rather than restoring anything that could carry persistence, and forcing credential resets across the board.
We build this plan with you in advance, alongside your cybersecurity controls, because the first hour of a ransomware incident is not when you want to be making architectural decisions.