Most people who run a backup believe they're protected. Then the day comes when a laptop dies, a ransomware payload encrypts a shared drive, or a hosting account gets suspended, and they discover that the backup they paid for either hasn't run since March, can't be opened without a license key they lost, or restores only half the files. The gap between "we have backups" and "we can restore" is where most data loss actually happens, and it's the gap this guide is designed to close. Offsite backup software sits at the center of that problem. Keeping a copy of your data in a different physical location (a different building, a different city, a different cloud region) protects you from fire, theft, flooding, and the kind of localized failure that takes out both your computer and the external drive plugged into it. Yet the category is crowded with tools that look nearly identical on a pricing page and behave very differently when you actually need them. Restore speed, versioning behavior, encryption key handling, and how the tool fails silently all matter more than the feature checklist. This article takes a restore-first view. Instead of asking "which tool has the most features," we'll ask "which tool will I trust at 2 a.m. when I need last Tuesday's version of a spreadsheet back." You'll get a practical definition of offsite backup, a worked example with real numbers, a comparison of the main approaches, and a step-by-step method for testing any tool before you rely on it. If you also manage a Windows machine and want a local-first view of the same question, our breakdown of Windows backup software in 2026 covers the on-device side of the picture.
Key Takeaways
- An offsite backup is only useful if you can restore from it, so test restores before you trust a tool, not after a disaster.
- Follow the 3-2-1 rule: three copies of your data, on two different media types, with one copy stored offsite.
- Encryption you control matters. If the vendor loses your key, your backups may be unrecoverable even though they technically exist.
- Check versioning and retention. A backup that only keeps the latest copy will happily replicate a ransomware-encrypted file across every snapshot.
- Measure restore time against your real recovery objective. Downloading 800 GB over a 20 Mbps connection takes roughly three and a half days.
- Pricing per gigabyte hides the real cost, which includes egress fees, storage tiers, and the hours you spend babysitting a failing job.
What Is Offsite Backup Software, Exactly?
Offsite backup software is a program that copies selected data from your device or server to storage located outside your premises, typically over the internet to a cloud provider or a remote server you control. The defining feature is geographic separation: the copy survives events that destroy the original location. Local backups to an external drive are useful for accidental deletion, but they share a building with the source data and fail together with it.
Most offsite tools fall into three broad groups:
- Managed cloud backup services that handle storage, scheduling, and encryption for you, usually on a per-device or per-user subscription.
- Bring-your-own-storage tools that encrypt and send data to a bucket you pay for directly, such as an S3-compatible object store or a Backblaze B2 account.
- Sync-style tools that keep a mirrored folder in a cloud drive. These are convenient but often lack true point-in-time versioning, which makes them weaker as backups.
The distinction between a sync tool and a backup tool is the one people most often get wrong. Sync propagates changes instantly, including deletions and corruption. A backup keeps history so you can go back in time. If your tool cannot tell you what your files looked like on a specific date, it is a sync service that you are using as a backup.
How Do You Judge Whether a Backup Tool Will Actually Restore?
Judge a tool on the restore path first, then the backup path. Most evaluation guides do the reverse, spending pages on how the software copies files and almost nothing on how it gives them back. Five questions tell you most of what you need.
- Can you restore individual files and full systems, and how long does each take? A tool that only offers full-disk restore to identical hardware is a poor fit for a single corrupted document.
- Who holds the encryption key? If the vendor holds it, they can help you recover data but also be compelled to hand it over. If you hold it and lose it, nobody can recover your data, including the vendor.
- How many versions does it keep, and for how long? Look for point-in-time versions with a retention policy you can configure. Ransomware is the main reason this matters: if the tool keeps only one copy, an encrypted file replaces the clean one within a single backup cycle.
- Does it verify backups? Good tools run integrity checks on stored data and report failures. Bad tools report "success" when the upload started, not when it finished.
- What does it do when something fails? Read the documentation for alerting. A job that fails quietly for six weeks is the most common horror story in this space.
Worked Example: Sizing a Restore Against Your Connection
Suppose you run a small design studio with a file server holding 800 GB of active project files, and your office internet provides 100 Mbps download speed. Here is what a full restore actually costs you in time.
- Convert 800 GB to bits: 800 × 8 = 6,400 gigabits.
- Divide by 0.1 Gbps (100 Mbps): 6,400 ÷ 0.1 = 64,000 seconds.
- Convert seconds to hours: 64,000 ÷ 3,600 ≈ 17.8 hours, assuming perfect throughput.
Real-world throughput usually runs at 60 to 80 percent of the advertised speed once you account for protocol overhead, provider throttling, and decryption. Plan for 22 to 30 hours. If your business can tolerate two days of downtime, that's fine. If it cannot, you need a local copy of the most recent data, or a tool that supports seeding restores from a physical drive shipped by the provider. Many managed services offer exactly that option for a fee, so ask before you sign.
Now compare that to a restore of only the 40 GB of current-quarter projects. At the same effective rate of roughly 70 Mbps, that's about 76 minutes. Selective restore is one of the most valuable features a tool can offer, and it's the one you'll use most often.
Which Offsite Backup Approach Fits Your Situation?
The right tool depends on what you're protecting, how much you can spend on storage, and how technical your team is. The table below compares the main approaches on criteria that matter for restores. Figures are representative of typical market offerings in 2026 and should be verified against current pricing before you buy.
| Approach | Typical cost (per TB/month) | Versioning | Key control | Restore friction | Best for |
|---|---|---|---|---|---|
| Managed cloud backup (per device) | Often $5 to $10 per device, flat | Usually 30 to 365 days | Vendor-managed or optional own key | Low, guided UI | Individuals and small offices |
| Bring-your-own object storage | Roughly $5 to $7 for storage, plus egress | Configurable, depends on tool | Full (you hold keys and bucket) | Medium, needs setup | Technical users wanting control |
| Cloud sync folder | Bundled with storage plans | Limited, often short | Account-level only | Low, but deletions propagate | Collaboration, not backup |
| NAS replication to remote site | Hardware plus bandwidth | Snapshot-based, strong | Full | Medium to high | Businesses with a second office |
| Hybrid (local plus offsite tier) | Varies widely | Strong | Mostly full | Low for local, higher offsite | Teams needing fast local and safe offsite |
A pattern emerges from the table. Cheap flat-rate plans usually trade control for convenience, and you pay for that trade at restore time. Bring-your-own storage gives you full control but makes you responsible for every failure mode. Hybrid setups are often the most resilient, because a local copy answers the common case (a deleted folder) quickly, and the offsite copy answers the catastrophic case slowly but reliably.
How Should You Set Up an Offsite Backup Step by Step?
A tool is only as good as its configuration. Follow this sequence whatever product you choose.
- Inventory your data. List every location that holds something you cannot recreate: documents, email archives, databases, project repositories, browser profiles with saved work. Write down approximate sizes.
- Define two targets. Recovery Point Objective (how much data you can afford to lose, for example 24 hours) and Recovery Time Objective (how long you can be down, for example 4 hours). These numbers decide your schedule and whether you need a local tier.
- Choose your key strategy before you upload anything. Generate a strong passphrase, store it in a password manager and in a sealed physical copy, and confirm that the tool supports recovery without the vendor. Do this first, because retrofitting encryption later is painful or impossible.
- Apply the 3-2-1 rule. Keep three copies: the live data, a local backup on a second medium, and an offsite copy. Each tier should use a different failure domain.
- Set versioning and retention. A reasonable starting point is hourly versions for 48 hours, daily for 30 days, and weekly for 12 weeks. Adjust for your storage budget.
- Enable verification. Schedule a monthly integrity check and confirm it sends you an email on failure, not only on success.
- Run a test restore. Pick one random file from three months ago and restore it to a new folder. Then restore a full project folder to a different machine. Time both. Record the result in your recovery document.
- Document the restore procedure. Write the steps in plain language, include where the key is stored, and keep a copy outside your office. The person doing the restore may be you during an emergency, when your memory is unreliable.
- Repeat the test quarterly. Backups degrade silently through expired credentials, changed folder paths, and software updates. A quarterly test catches most of these before they matter.
A Before-and-After Scenario
Consider a freelance developer named Priya who keeps 47 active client repositories, a shared Google Drive of invoices, and a local Lightroom catalog of 210 GB of photos. Before she reorganized,
