The question is never whether you have a backup. It is how long you would be down, how much work you would lose, and whether anybody has ever tested it.
Nearly every business we walk into has something they call a backup. A drive plugged into the server. A folder syncing to a cloud account. A job somebody set up years ago that has been emailing reports to a person who no longer works there. All of it counts as a backup right up until the day it has to work.
Recovery is a different question, and it is the only one that matters. How long until people can work again? How much of yesterday do you have to redo? Does the backup include the operating system and the applications, or only files, meaning somebody must first rebuild a server from nothing? Has anyone ever actually restored from it, or does the whole plan rest on the assumption that it would probably work?
We have seen every version of this go wrong. A backup drive encrypted alongside the server because ransomware reached everything on the network. A cloud sync that faithfully replicated the encrypted files over the good ones. A backup job that failed silently in February and was discovered in October. In each case the business believed it was protected, and the belief was the whole problem.
So we work backwards from recovery. You tell us how long you can be down and how much work you can afford to lose. We design backups to hit those numbers, we test them until we can prove they do, and we write the plan down so nobody is improvising during the worst week of their year.
What You Are Actually Protecting Against
A backup design that answers only one of these leaves you exposed to the other three, and they do not arrive in the order you expect.
The most likely disaster a small business will actually face. Modern ransomware crews look for and destroy your backups first, then encrypt everything else, because a company with clean backups does not pay. Whether you recover in a day or spend three weeks rebuilding is decided entirely by choices made before the attack.
Drives fail, power supplies fail, RAID controllers fail, and servers do it without warning on an ordinary Tuesday. This is the boring disaster, it is the most common one, and it is the reason a full system image beats a folder of copied files every time.
Western Kentucky knows what severe weather does. A sprinkler head, a roof leak, a lightning strike, or a tornado does not care how good your on-site backup is if the backup is sitting three feet from the server. This is the specific risk the off-site copy exists to answer.
Somebody deletes the wrong folder, overwrites a spreadsheet, empties a mailbox, or wipes a share while cleaning up. It causes more data loss incidents than every attacker combined, and it is the one where version history and retention depth matter more than anything else.
The Rule That Still Works
Three copies, two types of storage, one off-site. It has survived every change in technology because each part defends against a different way of losing everything.
An on-site copy on separate storage from the production system. This is what you restore from for ordinary events: a deleted folder, a corrupted database, a failed drive. It is fast because it never crosses the internet.
A second copy on a different kind of storage, so a failure mode that takes out one device does not silently take out both. Two backups on the same array are one backup wearing a disguise.
Encrypted, geographically separate, and locked against deletion for a retention window. This is the copy that survives the fire, the flood, the theft, and the attacker who got domain administrator rights three weeks ago.
The modern amendment is immutability. Ransomware groups learned years ago that the fastest way to guarantee payment is to delete the backups first, and they now spend days quietly inside a network doing exactly that before triggering encryption. An off-site copy that your own administrator account can delete is an off-site copy an attacker can delete. Immutable storage removes that option for a defined window, and it is the difference between an inconvenient week and an existential one.
This is why backup and cybersecurity are not separate conversations. The backup is your last line, and attackers know it, so it has to be designed as a security control rather than as a storage chore.
What We Provide
Software is the easy part. Everything below is the part that determines whether it saves you.
Full system images rather than file copies, so recovery means bringing the whole machine back as it was rather than rebuilding a server from scratch and then restoring data onto it. That difference alone typically turns a two-day recovery into a two-hour one.
Encrypted copies stored away from your building, with immutability so they cannot be modified or deleted for a defined retention period, even by someone holding your administrator credentials. This is the single most important control against modern ransomware.
Separate backup of Exchange Online, OneDrive, SharePoint, and Teams. Microsoft replicates your data for availability, which is not backup. If a file is deleted or encrypted, the deleted or encrypted state is what gets replicated.
Every job checked daily with alerts on failure, because the classic small business disaster is not a missing backup, it is a backup that quietly stopped working eight months ago and nobody noticed until the morning it was needed.
Scheduled test restores, including full system recovery into an isolated environment. This is how a recovery time stops being an estimate and becomes a measured number you can put in a plan and hand to your insurance carrier.
Restore order, system dependencies, credentials, vendor contacts, and who calls whom. During a real outage the order of operations matters as much as the data, and nobody thinks clearly at 4am without a document to follow.
Two Numbers, Plain English
Recovery time objective is how long you can be down before it genuinely damages the business. Not how long you would like it to be, how long you can survive. For a clinic running scheduling and charting that may be two hours. For a workshop it may be two days.
Recovery point objective is how much work you can afford to redo. If backups run nightly and the server dies at four in the afternoon, you have just lost a full day of everybody’s work. Businesses that cannot accept that need backups running hourly, and that is a design decision, not an accident.
Every technical choice we make flows from those two numbers: how often jobs run, whether we image or copy files, where copies live, and how quickly they can come back. Pick the numbers first and the technology stops being a debate.
Cyber insurance carriers increasingly ask for exactly this list, in writing, before they will quote or pay. Having it prepared is worthwhile even in the years when nothing goes wrong.
FAQ
They are the only two numbers that matter, and both are business decisions rather than technical ones. RTO, recovery time objective, is how long you can be down before it genuinely hurts. RPO, recovery point objective, is how much work you can afford to redo. If your backup runs nightly at 10pm and the server dies at 4pm, your RPO means you just lost a full day of work. A law office may be fine losing an hour and being down half a day; a clinic running scheduling and charting cannot lose either. We ask you for those two numbers in plain terms, then design backups to hit them, instead of installing something and hoping the numbers work out.
Three copies of your data, on two different kinds of storage, with one of them off-site. It survives because it defends against three different disasters at once. Three copies means a single corrupted backup does not end you. Two media types means a failure that takes out one device does not take out both. One off-site copy means a fire, flood, theft, or ransomware event that reaches everything in your building still leaves you something. The modern addition is that the off-site copy should also be immutable, meaning it cannot be altered or deleted for a set period even by someone holding your administrator credentials, because ransomware crews now specifically hunt for and destroy backups before they encrypt anything.
It is better than nothing and it is not a disaster recovery plan. A USB drive sitting next to the server shares every risk the server has: fire, water, theft, a power surge, and above all ransomware, which will encrypt any attached drive it can reach. It also usually holds files rather than a full system image, which means recovering from it involves rebuilding a server first and then restoring data onto it, turning a two-hour recovery into a two-day one. Keep the local drive for speed, add an off-site copy for survival.
The first step is containment, not restoration. We isolate affected machines from the network so encryption stops spreading, then work out what got in and when, because restoring to a point after the intrusion just reinfects you. From there we verify the backups are clean, rebuild or reimage the affected systems, and restore in a documented order: domain and authentication first, then line-of-business applications, then file data, then everything else. Businesses that recover in a day are the ones whose off-site backups were out of reach and whose restore order was written down beforehand. Businesses that pay ransoms are almost always the ones whose only backup was on the network that got encrypted.
No, and this catches people out constantly. Both replicate your data across their infrastructure so it survives their hardware failures, which is a different thing entirely. If a file is deleted, overwritten, or encrypted, that state is replicated too. Retention windows for deleted items are short and unforgiving, and Microsoft explicitly recommends third-party backup in its own service agreement. Any business running its email and files in the cloud needs separate backup of Exchange Online, OneDrive, SharePoint, and Teams. It is inexpensive and it is the gap we find most often.
You test them, on a schedule, and you write down the result. An untested backup is a belief, not a safeguard, and roughly the worst moment to discover a backup has been silently failing for eight months is the morning your server does not come up. We monitor every backup job daily, alert on failure rather than waiting for someone to check a dashboard, and perform periodic test restores including full system recoveries into an isolated environment. That test is also how we produce a real recovery time number instead of an estimate, which is the number your insurance carrier and your auditors will eventually ask for.
Recovery is what you do when prevention fails, so we build both together as part of our IT services in Murray, KY. See also cybersecurity, Microsoft 365, and managed IT services, which is how most clients keep all of it monitored month to month.
We will review what you have, tell you honestly how long a recovery would take today, and show you what it would cost to shorten it. In writing, no obligation.
Murray, KY 42071 • Serving Calloway County and western Kentucky
Ready to Transform Your Technology?
Let’s discuss how we can help streamline your IT infrastructure, improve security, and accelerate your business growth with our comprehensive technology solutions.
Ready to discuss your technology needs? Our team of experts is here to help you find the perfect solution for your business. Contact us today for a free consultation.
Phone
(270) 807-1000Service Area
Murray, KY & Western Kentucky — Remote Support Available Nationwide
Support Hours
24/7 Emergency Support
For urgent technical issues or emergency support, our team is available 24/7 to ensure your systems stay operational.