Should backups live on a local server or in the cloud? The honest answer is that each option is strong where the other is weak. This article compares them on the criteria that matter during a real incident, restore speed, resilience, security and cost, and explains how to combine them.
Definitions
Local backup means copies stored on hardware you control, near the systems they protect: a backup server, a NAS, a Proxmox Backup Server, external disks or a tape library in the same building.
Cloud backup means copies stored with an external provider, usually in object storage reached over the internet, in a region you choose.
Comparison
| Criterion | Local backup | Cloud backup |
|---|---|---|
| Restore speed | High: limited by your local network and disks | Limited by internet bandwidth and provider egress |
| Protection against site loss | None if stored in the same location | Strong, if the region is far from your site |
| Protection against ransomware | Weak if reachable from the same network and credentials | Strong with immutability and separate credentials |
| Upfront cost | Hardware purchase | None |
| Ongoing cost | Power, space, replacement, administration | Monthly storage fee; possibly egress and requests |
| Scalability | Requires buying and installing hardware | Capacity is added on demand |
| Data residency control | Full: data stays on your premises | Depends on the region chosen |
| Maintenance | Your team handles disks, firmware, failures | Provider handles storage infrastructure |
Where local backup wins
Recovery time
Restoring 2 TB over a 10 Gbit/s local network can take well under an hour if disks keep up. The same restore over a 200 Mbit/s internet connection takes roughly a day. When an important system must be back within hours, a local copy is hard to beat.
Frequent, granular restores
Most restores are small: a deleted folder, last week's version of a configuration file, a single table. Local copies make these daily requests quick and cost nothing in egress.
Large initial datasets
Uploading tens of terabytes for the first time can take weeks on a typical connection. A local copy protects you while the offsite copy is still being seeded.
Where cloud backup wins
Surviving the loss of the site
Fire, flood, theft, a building power problem or a compromised network can take out production and any backup stored next to it. A copy in another region is the only thing that survives these events.
Resistance to ransomware
Object storage with immutability (S3 Object Lock) and credentials that are not present on production systems keeps a clean copy even when attackers control your servers. Local backup servers can achieve a similar level of protection, but they require careful isolation that is often skipped.
No hardware lifecycle
No disks to replace, no capacity planning in units of whole servers, no backup appliance reaching end of support. You pay for the capacity you use.
Where each one fails
Local backups fail when the site fails, when the backup server is reachable by the same attacker, and when nobody notices that a disk in the backup array died months ago. Cloud backups fail when the internet link is too slow to restore within your deadline, when egress costs were not budgeted, when credentials with delete rights live on production servers, and when encryption keys are stored only on the systems being protected.
The hybrid approach
For most organizations, the right answer is both: a local copy for speed and a cloud copy for resilience. This is the core of the 3-2-1-1-0 rule.
- Back up production to a local backup server or NAS, on separate hardware.
- Replicate those backups, or run a second backup job, to cloud object storage in another region.
- Make the cloud copy immutable or reachable only with credentials that production does not hold.
- Restore day-to-day requests from local; use the cloud copy for disasters and as a fallback when local copies are damaged.
Cost: compare total cost, not storage price
A fair comparison includes everything:
- Local: hardware amortized over its life (typically 3 to 5 years), spare disks, power and cooling, rack space, administration time and the cost of a second site if you want offsite protection with your own hardware.
- Cloud: monthly storage, request fees if any, egress during restores or tests, and the bandwidth needed for daily uploads.
Deduplication, compression and retention policies change both sides dramatically. Use the method in how much cloud backup storage you need before comparing prices.
Security checklist for both
- Encrypt backups at rest and in transit. With cloud storage, prefer client-side encryption so data is encrypted before it leaves your network.
- Use separate credentials for backup storage, with the least privileges needed.
- Enable multi-factor authentication on consoles that can delete backups.
- Keep encryption keys in at least two safe places that do not depend on the protected systems.
- Log and monitor deletions and retention changes.
Decision guide
| Your situation | Suggested approach |
|---|---|
| A few servers, no spare hardware, modest data | Cloud backup with immutability; optional local copy on a NAS |
| Proxmox cluster or many VMs | Local PBS for fast restores plus offsite copy in the cloud |
| Strict on-premises data residency | Local backups plus an offsite copy in a second own site or an in-country cloud region |
| Recovery time of minutes for large systems | Local copies or warm standby; cloud as the disaster copy |
Next steps
- Measure your restore bandwidth from the cloud and calculate how long a full restore of your largest system would take.
- Check whether your current backups would survive the loss of the building and the compromise of an administrator account.
- Define recovery objectives per system with RPO and RTO, then choose where each copy lives.
Backnix is designed to provide the encrypted offsite copy in a hybrid strategy, in the region you choose. See cloud storage and pricing.