An offsite backup is a copy of data stored at a location physically separate from the primary systems, far enough away that an event destroying the main site does not also destroy the backup. In backup & recovery for servers, the offsite copy protects against site-level disasters such as fire, flood, power failure, theft or a compromised data center, which no amount of local redundancy can survive.
Offsite storage is one of the three conditions of the 3-2-1 backup rule: three copies of data, on two different media, with one copy offsite. The offsite copy can live in another data center, in cloud object storage or on removable media kept in a secure vault, and it is the copy that makes disaster recovery possible at all.
Why offsite backups are needed
Local backups and RAID arrays protect against component failures, but they share the fate of the building they sit in. A fire that destroys the server room destroys the backup server in the same room as well. The purpose of an offsite backup is to break this shared fate by placing a copy beyond the reach of any single local event.
Ransomware has made offsite copies even more important. Attackers who gain administrator access often delete or encrypt every backup they can reach over the network before they encrypt production data. An offsite copy that is immutable or air-gapped survives such an attack, while an offsite copy that is simply another writable network share may be lost along with everything else.
Methods of moving backups offsite
Organizations move data offsite with several methods that differ in cost, speed and protection level. The table below compares the most common ones.
| Method | How data travels | Restore speed | Main strength |
|---|---|---|---|
| Cloud object storage | Encrypted upload over the internet | Limited by bandwidth | No hardware to manage, object lock available |
| Secondary data center | Replication over a WAN link | Fast, often at near-local speed | Supports quick failover of whole systems |
| Tape vaulting | Cartridges shipped to a vault | Hours to days including transport | Low cost per terabyte, natural air gap |
| Rotated removable disks | Drives carried to another site | Moderate after retrieval | Simple for small organizations |
| Managed backup service | Agent sends data to a provider | Depends on the provider and plan | Monitoring and retention handled externally |
Modern tools such as Restic, Borg and rsync-based scripts make cloud and remote-server targets easy to use. Deduplicating tools upload only changed chunks, which keeps daily transfer volumes small after the first full upload, while encryption on the client side ensures that the remote location never sees readable data.
Key design parameters
An offsite backup design is defined by a few parameters that must match the organization’s recovery objectives. The table below lists them with typical ranges.
| Parameter | Typical range | What it decides |
|---|---|---|
| Distance from primary site | Tens to hundreds of kilometers | Which regional disasters the copy survives |
| Copy frequency | Continuous to weekly | The achievable recovery point objective |
| Retention period | 30 days to several years | How far back data can be restored |
| Transfer bandwidth | Tens of Mbit/s to several Gbit/s | Whether nightly changes finish within the backup window |
| Encryption | AES-256 with client-held keys | Confidentiality at the remote location |
| Immutability period | Days to months of object lock | Protection against deletion and ransomware |
Bandwidth deserves careful calculation. Uploading 10 TB over a 100 Mbit/s link takes roughly nine days at full speed, so the first seeding of an offsite copy is often done by shipping a physical drive to the provider. Restoring a whole environment over the same link would take just as long, which directly affects the recovery time objective (RTO).
Offsite backup compared with related concepts
Offsite backup is often confused with replication and snapshots, which serve different purposes. The comparison below clarifies the differences.
| Method | Protects against site loss | Protects against deletion or corruption | Typical role |
|---|---|---|---|
| Offsite backup | Yes | Yes, through retained versions | Last line of recovery |
| Local backup | No | Yes | Fast everyday restores |
| Snapshot | No, unless copied offsite | Partly, until snapshots are deleted | Quick rollback on the same storage |
| Live replication | Yes | No, errors replicate instantly | Fast failover and high availability |
| Air-gapped backup | Yes, when stored offsite | Yes, even against network attacks | Ransomware-resistant copy |
The key lesson is that replication is not backup. A replica mirrors every change, including accidental deletions and encrypted files, within seconds. Only a copy with independent version history allows a return to a point before the damage occurred.
Common mistakes with offsite backups
Many offsite backups exist on paper but fail during an actual disaster. These are the most frequent causes.
- Never testing a restore. Regular restoration tests from the offsite copy are the only proof that it is complete and usable.
- Storing encryption keys only on the primary site. If the keys burn with the building, the offsite copy cannot be decrypted.
- Using the same credentials for production and backup storage, which lets an attacker delete both.
- Choosing a location too close, such as another building on the same floodplain or power grid.
- Silent job failures that leave the offsite copy weeks out of date without anyone noticing.
Stripped to the essentials
An offsite backup is a spare copy of your data kept somewhere else. If the office or server room burns down, floods or is broken into, the spare copy is still safe in another place.
It works like keeping copies of important family documents at a relative’s house. A copy in the same drawer helps if you lose the original. Only a copy in a different building helps if the whole house is lost.
Where it is applied
A regional accounting firm keeps client records on two file servers in its office and backs them up every night to a local backup appliance. During a review, the firm realizes that a single fire or a ransomware attack could destroy the servers and the appliance together.
The firm adds a nightly encrypted upload to cloud object storage in a region about 300 kilometers away, with object lock set to 30 days and separate credentials held by two partners. The first 4 TB are seeded on a shipped drive, and nightly changes of about 20 GB then finish in under an hour. A quarterly restore test recovers a full client folder from the cloud copy, and the firm can now recover even after losing the whole office.