A VPS accumulates dead weight: retired client sites, old staging copies, image archives and databases nobody queries anymore. Keeping them on block disk is the default because it is easy, and it is usually the most expensive option per gigabyte once the data stops being read. The three realistic alternatives have very different cost and restore profiles.
The baseline you are comparing against is your current plan’s disk cost per GB, which typically falls between $0.10 and $0.30 per GB per month on budget tiers. Anything that beats that per GB is worth considering, provided restore time stays inside your tolerance. You can see what each tier includes on our VPS comparison table.
What Each Storage Class Is Good At
| Storage class | Typical $/GB/mo | Retrieve time | Best fit |
|---|---|---|---|
| VPS block disk (ext4/xfs) | $0.10 – $0.30 | Instant | Live data, hot backups |
| Compressed snapshot on same provider | $0.05 – $0.10 | 5 – 30 min | 30 to 90 day rollback |
| Object storage standard tier | $0.015 – $0.023 | Seconds | Static archives, media |
| Object storage cold/archive tier | $0.004 – $0.005 | Minutes to hours | Legal retention, dead sites |
These are list prices before request charges and egress. Object storage bills per 1,000 requests and per GB retrieved, which is irrelevant for a site nobody visits and material for one that is browsed weekly.
The Real Cost of a Dead Site on Block Disk
A typical archived WordPress install is 2 to 6 GB including uploads and a database dump, plus the OS. If it lives on a $6/month 25 GB plan alongside a live site, it is consuming 20 to 25 percent of the plan’s capacity and pushing the live site toward an upgrade that would otherwise not be needed.
Quantify it: an upgrade from a 25 GB plan at $6 to a 50 GB plan at $12 costs $72 a year. The same 5 GB of archive data in cold object storage costs roughly $0.30 a year plus a few cents of request charges. The delta is the entire argument.
Compressing Before You Move Anything
Before choosing a destination, shrink the payload. A database dump of a WordPress site compresses 4 to 8 times with zstd -19 or gzip -9; a tarball of a static site often compresses better than 10 times. A 5 GB archive usually becomes 600 MB to 1.2 GB.
Compression changes the comparison: at 800 MB, even the archive tier’s savings are small in absolute dollars, and the thing you are really buying is removing the maintenance burden of a running stack, not the storage fee.
Building the Archive Package
A complete archive has five parts and most hand-made ones have three. Include the web root, a database dump, the web server and PHP or application config, the TLS certificate and private key if you keep your own, and a manifest file that names the original domain, the software versions and the date.
Write the manifest as plain text. In two years the person restoring it will not remember which PHP version the site ran on, and a 200-word note costs nothing while a failed restore costs an evening. Store a copy of the restore steps alongside the archive, not only in your head.
- Web root tarball:
tar --zstd -cf site.tar.zst /var/www/example - Database dump:
mysqldump --single-transaction --routines | zstd -19 - Config: nginx vhost, PHP-FPM pool, cron entries, systemd units
- Certs and DNS: certificate, key, and a note of the DNS records in use
- Manifest: domain, versions, date, restore commands
Restoring Is the Part People Get Wrong
A restore plan that has not been timed is not a restore plan. For each archived site, record how long it takes to pull the object, decompress it, recreate the database and verify the homepage returns 200. Cold tiers add a retrieval request that can take hours to complete on the provider’s schedule, not yours.
Test one restore end to end before trusting the arrangement. The common failure mode is not lost data but a missing piece: the archive contains files but not the database dump, or the dump but not the uploads directory, or both without the SSL certificate and DNS record.
| Restore drill step | Expected time | Common failure |
|---|---|---|
| Retrieve from cold tier | 1 – 6 h | Not requested early enough |
| Decompress and unpack | 2 – 10 min | zstd missing on target host |
| Import database | 1 – 15 min | Dump lacks routines or triggers |
| Recreate vhost and cert | 10 – 30 min | Cert key not archived |
| Verify 200 and assets | 5 min | Absolute URLs pointing at old domain |
What to Keep on the VPS Anyway
- Recent backups: the last 14 to 30 days stay on block disk or provider snapshots for fast rollback.
- Anything inside an RPO of 24 hours: object storage restore latency exceeds it.
- Data with an active compliance hold: keep a copy on durable storage with versioning, not only in a cold tier.
- Configuration for the archive pipeline itself: the script, credentials and manifest live in version control, not only on the server.
A Workable Tiering Layout
Keep live data and 30-day backups on block disk. Move monthly full backups older than 30 days to object storage standard, where they are still downloadable in seconds. Move everything older than 12 months, plus retired sites, to the archive tier with a manifest and a restore note.
Budget the egress explicitly. Most object storage providers charge nothing for upload and $0.08 to $0.09 per GB to download; restoring a 5 GB archive once costs under $0.50, which is fine, but restoring it every week is a sign the data should not have been archived yet.
Automate the move with a small cron job rather than by hand: find archives older than the threshold, upload, verify the checksum server-side, then remove the local copy. Delete only after the checksum matches, and keep the last local copy of anything that has not been verified.
Where This Fits Against Your Plan
The decision usually maps to whether you need the next tier up. Freeing 20 to 30 percent of disk by tiering archives is often enough to stay on a smaller plan for another year, and that saving is larger than any storage price difference. Check what capacity each tier actually includes on our VPS comparison table before assuming an upgrade is the answer.
Start with the largest single archive, compress it, move it, and time the restore. If the process is clean, apply it to the rest; if it is not, you have learned that in one evening rather than during an incident.


