A retention policy is a storage multiplier, and on a budget VPS the multiplier usually costs more than the plan. Daily backups kept for 30 days sound modest until you count the weekly and monthly copies layered on top, and until you notice that a full snapshot of an 80 GB volume at $0.10/GB is $8 per copy, not $0.80.
Grandfather-father-son (GFS) rotation is the standard compromise: frequent recent copies, sparse older ones. The arithmetic below sizes a backup target for a $5–$20 VPS without overbuying, and shows where compression and deduplication change the answer by a factor of three.
What GFS actually retains
GFS layers three schedules. Son: daily backups kept for a short window, typically 7–14 days. Father: weekly backups kept for 4–8 weeks. Grandfather: monthly backups kept for 6–12 months. Each layer is separate retention, so a 14-day son window plus 8 weekly plus 12 monthly does not mean 34 independent generations — the schedules overlap and prune each other.
The common mistake is counting every schedule independently and assuming the windows add. A daily backup taken on the first of the month becomes that month’s grandfather, not an additional copy. Implemented correctly, the steady-state copy count is roughly the sum of the non-overlapping slots, not the sum of every backup ever scheduled. Get that wrong and you plan for twice the storage you need, or half.
The retention count, worked out
Take a practical policy: 14 daily, 8 weekly, 12 monthly. With overlapping pruning, steady state is about 14 + 8 + 12 = 34 copies, but the 8 weekly and 12 monthly snapshots often coincide, so a well-built rotation lands near 30. Round up to 34 for planning; the difference matters less than the volume size.
Now multiply. A 40 GB volume with 35% filesystem utilisation holds roughly 14 GB of real data. Thirty-four full copies is 476 GB of stored data. At $0.02/GB on block storage that is $9.50 per month — nearly double a $5 VPS. This is the point where most budget plans quietly become expensive, and it is also the point where most people start deleting backups to save money rather than changing the strategy.
Keep the arithmetic anchored to real block counts, not logical sizes. du -sh --apparent-size overstates what will land in the target once sparse files and hardlinks collapse, while df understates it if the backup tool stores metadata separately. Use du -sh without flags as your planning figure and add 10% for index overhead.
Full copies versus incremental chains
Every full copy is independent and costs the full data size. Incrementals cost only changed blocks but form a chain: lose a middle link and every later restore point is invalid. A common budget compromise is weekly fulls with daily incrementals, which caps the chain at six links and keeps the restore path short.
With restic or borg, the distinction collapses: both store content-addressed chunks and reconstruct any snapshot without a long chain. A daily restic run over 14 GB of mostly-static data typically adds 200–800 MB per day after the first backup, which changes the storage projection dramatically.
Compression: measure, do not assume
Compression ratios depend entirely on content. Text, HTML, logs and SQL dumps compress 3:1 to 8:1. JPEGs, MP4 and already-compressed archives compress close to 1:1, and encrypted containers do not compress at all. Run tar -cf - /var/www | zstd -19 -o /dev/null and read the reported ratio before planning around it.
A WordPress site with a media library is usually 15–25% compressible overall, because images dominate the byte count. A database dump is often 70–80% compressible. Sizing a whole backup target at a single blended ratio is how people run out of space in week three. Run the test on each data class separately and weight the results by the share of bytes each one contributes.
Deduplication and the content-addressed saving
Deduplication removes duplicate chunks across snapshots. For a file server or a media library, the saving is large because most files never change. For a database, page-level changes make daily dedup savings much smaller — a Postgres cluster writes scattered pages constantly, so only a fraction of blocks repeat.
This is why a single retention number cannot be quoted for all workloads. The same 14 GB policy that costs 20 GB of storage with restic on a file server can cost 90 GB on a write-heavy database. Measure after a week of real backups, then multiply.
Sizing table for a typical policy
| Data size | Strategy | Stored per copy | 34 copies total | Monthly cost at $0.02/GB |
|---|---|---|---|---|
| 14 GB | Full daily, no dedup | 14 GB | 476 GB | ~$9.50 |
| 14 GB | Full daily, zstd 3:1 | 4.7 GB | 160 GB | ~$3.20 |
| 14 GB | restic dedup + zstd | 0.4 GB/day | ~30 GB | ~$0.60 |
| 40 GB | Weekly full + daily incr | 40 GB / 2 GB | ~55 GB | ~$1.10 |
| 40 GB | Restore from remote, 7 days only | 40 GB × 7 | 280 GB | ~$5.60 |
The gap between row one and row three is the entire cost argument. Retention windows multiply storage; deduplication divides it. Neither changes the number of restore points you can offer, only how many bytes each one costs.
Where to put the target
Do not store backups on the same provider as the VPS unless the storage is genuinely separate from the compute failure domain. A provider-level outage takes both. Object storage at $0.005–$0.015/GB per month is usually cheaper than block storage and survives instance deletion, which is the exact scenario backups exist for.
Budget arithmetic: 30 GB of deduplicated restic data in object storage costs well under $1 per month, plus roughly 50–200 MB of egress per restore. Compare that with $9.50 for full snapshots on block storage and the choice is not close. Our VPS plans include the instance storage; the backup target should live outside it.
One more multiplier people forget: egress on restore. A 40 GB restore at a $0.09/GB rate costs $3.60 — more than a year of object storage. Check restore pricing before you need it, and test one restore in the first week so the number is real rather than theoretical. That test is the difference between a backup policy and a backup policy that works, and it is the first thing to run on any affordable VPS setup.
