Every backup plan eventually arrives at the same awkward question: where does the copy that survives this building live, and what does it actually cost to keep it there?
The rule everyone quotes is 3-2-1 — three copies of the data, on two different media, with one of them offsite. CISA repeats it in its small-business guidance because it is the cheapest advice in security that still works. The first two parts are usually handled without anyone thinking hard: the live data, plus a snapshot on the same machine or a second disk. The third part is the one that gets deferred, and it is the only one that helps when the failure is a fire, a theft, a ransomware event, or an engineer running the wrong rm against the wrong host.
This is a sizing and costing guide for that third copy.
What the offsite copy is actually for
Be precise about the failure it covers, because that decides the design.
| Failure | Local snapshot helps? | Offsite copy helps? |
|---|---|---|
| Deleted a file an hour ago | Yes | Yes |
| Corrupt database table | Yes | Yes |
| Disk or array failure | Sometimes (RAID is not a backup) | Yes |
| Host compromised, snapshots deleted | No | Yes, if credentials are separate |
| Ransomware encrypts everything reachable | No | Yes, if the target is not a mounted share |
| Datacentre fire, seizure, or provider account loss | No | Yes |
The bottom four rows are the whole argument. Note the two conditionals: an offsite copy only survives a compromise if the credentials that reach it are not the same credentials the compromised machine holds, and if the target is not mounted as a writable filesystem on the machine being encrypted. A permanently mounted network drive in another country is still one find / -exec away from being part of the incident.
Sizing: work from restore, not from disk
The usual mistake is to size the offsite tier at "how big is my server" and stop. That number is wrong in both directions.
It is too big because you are not backing up the operating system. A reinstalled OS plus a configuration management run reproduces the machine; what cannot be reproduced is data. It is too small because you are keeping more than one point in time.
The arithmetic that works:
unique data × compression factor × number of retained points × change rate
Concretely: a 400 GB dataset that compresses to 250 GB, kept as a chain of 30 daily incrementals with a 2% daily change rate, needs roughly 250 GB for the full plus about 150 GB of increments — call it 400 GB, and buy 1 TB so a second full and a bad month do not wake anybody up.
Three things reliably blow this estimate:
- Databases dumped rather than snapshotted. A
mysqldumpis a text file. It compresses beautifully but deduplicates terribly — every dump is a new file, and thirty dumps is thirty full copies unless the tool does content-defined chunking. Restic, Borg and Duplicity all do; acronjob that gzips a dump into a dated filename does not. - Image and media directories. They do not compress and they only grow.
- Retention that nobody ever set. A job with no pruning policy grows without bound until an alert fires, and the alert is usually the invoice.
What offsite storage costs, honestly
Three pricing shapes exist, and the difference between them only shows up on the day you restore.
| Model | Storage | Egress on restore | Where it hurts |
|---|---|---|---|
| Hyperscaler object storage | Low per-GB headline | Metered per GB after the first 100 GB a month | A full restore is a surprise invoice |
| Egress-capped object storage | ~$6.95/TB/month (Backblaze B2, Sept 2026) | Free up to 3× stored volume, then $0.01/GB | Fine until a large restore exceeds the multiple |
| Flat-rate quota | Fixed per TB | None | Nothing, if the quota is right |
NexonHost's backup storage sits in the third row: a flat €5 per TB per month at every tier from 1 TB to 600 TB, with no setup fee, no per-request charge and no retrieval line item. A 600 TB account costs the same per terabyte as a 1 TB account, which is unusual — most ladders get cheaper at the top and punish the small buyer, or get more expensive at the top and punish success.
The reason to care about the egress column is that restores are correlated with bad days. The invoice for pulling 4 TB back arrives in the same week as the incident that made you pull it. Metered retrieval is a cost that is smallest when you never use the product and largest exactly when you need it, which is a strange thing to design a safety net around.
The connection matters more than the brand
Offsite backup storage is worth very little if it forces you to change your tooling. NexonHost's is presented as a plain chrooted SFTP account over SSH on port 22, which means the client list is "anything that speaks SFTP": sftp, rsync, rclone, Restic, Borg over SSH, Duplicity, Veeam, Proxmox Backup Server, FileZilla, WinSCP, or a NAS with an SFTP target. There is no proprietary agent to install and no vendor SDK in the restore path.
That last point deserves weight. A restore procedure that depends on a vendor's client being installable on whatever machine you have in front of you at 3am is a restore procedure with a dependency you cannot inspect. sftp is on every Linux box already.
A workable pattern for a single server
- Local snapshot for speed. Daily, on the machine or its host, for the ordinary "undo the last hour" case.
- Offsite push for survival. Daily, from the server to the SFTP account, using a tool with deduplication and a prune policy — Restic and Borg both do this well.
- Separate credentials. The offsite account gets its own key. It is not the same key that gets you into the server.
- Prune on a schedule, not on alarm. Keep 7 daily, 4 weekly, 6 monthly, or whatever your recovery-point objective actually requires; write it in the job, not in a wiki.
- Test the restore quarterly. Restore to a scratch VPS, not to production, and time it. The number you learn is your real recovery-time objective.
Step 5 is the one that gets skipped and the one that matters. An untested backup is a hypothesis.
Where this sits next to the rest of the stack
Offsite backup storage is not a substitute for capacity on the production side. If the working dataset itself is large — video, archives, log retention, a media library — the working copy belongs on a storage server or a storage VPS, and the backup account holds the copy of it. Buying one big backup quota and treating it as primary storage over SFTP works technically and disappoints operationally: latency and throughput to a backup tier are sized for sequential bulk transfer, not for a live workload.
Equally, a backup account does not replace redundancy in the machine. RAID protects against a disk dying at 2pm on a Tuesday; a backup protects against everything else. They solve different problems and you want both — see RAID levels explained for choosing the array, and VPS vs dedicated server for choosing what to protect.
Buying advice, briefly
Buy the tier above your calculation, because the failure mode of a full backup target is silent job failure. Check that usage against quota is visible in a dashboard you already look at — NexonHost shows it in the client area — so the ceiling announces itself before a job does. And keep the growth path cheap: because the storage is a plain SFTP quota, moving from 1 TB to 10 TB changes the number and nothing else, so no job gets rewritten and no host or credential changes.
The third copy is the cheapest insurance in infrastructure. At €5 per TB, a year of offsite backup storage for a typical single-server workload costs less than one hour of the incident it exists to survive.
Related reading: storage server vs storage VPS sizing, RAID levels explained, and what NIS2 asks of hosting providers.
Sources
- Back Up Business Data, CISA, retrieved 7 September 2026.
- B2 Cloud Storage Pricing, Backblaze, retrieved 7 September 2026 — $6.95/TB/month, free egress up to 3× stored data, $0.01/GB thereafter.
- Amazon S3 Pricing, AWS, retrieved 7 September 2026 — first 100 GB/month of data transfer out to the internet is free, aggregated across services and regions.
- Plan specifications and pricing as published on nexonhost.com on 7 September 2026; check the product page for current figures.
