Backup and disaster recovery
A backup that has never been restored is a hope, not a backup. We set up backups and then prove they work.
Testing
Backups that have actually been restored
The common failure is not an absent backup. It is a backup that has been running for two years, reporting success, and silently excluding the one folder that mattered. We verify restores rather than trusting the report.
Part of ongoing managed IT is checking this on a schedule, so the first test is not the day you need it.
Offsite
Onsite and offsite together
A local copy restores quickly. An offsite copy survives a fire, a flood or a theft. Most businesses need both, and the balance depends on how long you can afford to be down.
Rural New Hampshire adds a practical constraint: upload bandwidth. We size offsite backups around the connection you actually have, not the one on the brochure.
Planning
Deciding what recovery looks like
Two questions set the whole design: how much data can you afford to lose, and how long can you afford to be down? A business that can tolerate a day of downtime needs a very different arrangement from one that cannot tolerate an hour.
We would rather have that conversation before an incident than during one.
Ransomware
Why one copy is not enough
Ransomware encrypts what it can reach, and that includes backup drives left permanently connected and network shares the infected machine can write to. A backup that lives only on an always-connected drive is often encrypted along with everything else.
The protection is a copy the infected machine cannot reach: offsite, offline, or held so that it cannot be overwritten. That is the difference between an unpleasant week and a closed business.
Cloud data
Data that lives in cloud services
If your files and email are in Microsoft 365, they are not automatically backed up in the sense most people mean. Microsoft protects its own infrastructure; it does not protect you from a staff member deleting a folder and nobody noticing for three months.
Cloud data needs its own backup, and it is one of the most common gaps we find.
Hardware
Servers and the machines in the office
Workstations are usually replaceable; what hurts is the data on them and the time to rebuild. Where a business depends on a server, the recovery plan should say how that server comes back and roughly how long it takes, agreed in advance.
Questions
Frequently asked questions
How often should backups run?
It depends on how much work you can afford to redo. For most offices a daily backup is the baseline; for systems where a day of lost work is unacceptable, more frequent snapshots are appropriate.
Do you test that backups restore?
Yes. Verifying restores is part of ongoing managed support, because a backup that reports success and cannot restore is the most common failure we see.
Is cloud backup practical with rural internet?
Usually, with planning. We size the offsite copy around your actual upload speed, and seed the first full backup locally where the connection would make it impractical.
What happens if a server fails completely?
That is what the recovery plan covers: which systems come back first, from which copy, and how long each step takes. We agree that in advance rather than improvising.