How Much Backup Storage Does a VPS Need? A Worked Example

Published on

Measure your files and database dumps, then see how compression, deduplication and retention set the total, with a worked example for restic, borg and tar.

A VPS panel showing disk usage at 0.96 of 120 GB and a bandwidth meter with IN and OUT at 0%

You want your VPS backed up to another machine, and before you rent a second server, a storage box or a bucket, you need a number. "Twice the disk" misses both ways: much of the disk is an operating system you don't need to back up, while a year of history can store the same database many times over. The total depends on what you back up, how well it compresses, how much of it changes and how many snapshots you keep. Here's how to measure each on Ubuntu 24.04 and Debian 12, with a worked example.

Quick answer: Add up the folders you back up with du, plus one night of database dumps, and preview the compressed size with tar and zstd. restic and borg store that once, compressed, plus what differs in each snapshot you keep (up to 23 for a year of daily, weekly and monthly ones); tar.gz archives need a full copy each. Compressed dumps deduplicate poorly, so keep only the newest dump on the server and let the backup tool keep the history. After a week, check the real growth in restic's Added to the repository lines or borg's deduplicated size, and leave room for a year of growth and for pruning.

Step 1: Measure What You Back Up

Start from your include list. These are the folders from our restic guide; drop any you don't have:

sudo du -xsch /etc /home /root /srv /opt /var/www /usr/local /var/backups /var/spool/cron/crontabs
sudo du -xh -d2 /home /srv /var/www | sort -h | tail -n 15

-s gives one total per folder, -c a grand total, -x stays on one file system and -h counts in powers of 1024, like restic's GiB (borg uses powers of 1000). The second line lists the biggest subfolders. Caches your backup excludes are still counted, so the real figure is a little lower.

Leave out the database folders under /var/lib and back up dumps instead, as the restic guide explains. Nightly dumps from our PostgreSQL, MariaDB or Docker volumes guides are already in the /var/backups total, and sudo ls -lh /var/backups/*/ lists them. No dumps yet? The databases' own sizes give a first idea:

sudo -u postgres psql -c "SELECT datname, pg_size_pretty(pg_database_size(datname)) FROM pg_database ORDER BY pg_database_size(datname) DESC;"
sudo mariadb -e "SELECT table_schema, ROUND(SUM(data_length + index_length) / 1024 / 1024) AS size_mb FROM information_schema.TABLES GROUP BY table_schema ORDER BY size_mb DESC;"
sudo docker system df -v

pg_database_size is the disk space a database uses, and the MariaDB query adds up data and index sizes, like the example in MariaDB's docs. A dump holds SQL commands or pg_dump's archive format, not the database files, so its size differs: use a real dump as soon as you have one. docker system df -v lists each volume's size under Local Volumes space usage.

Step 2: See How Much It Compresses

In a version 2 repository, which our restic guide creates, restic's default compression uses a zstd setting that its compression library rates roughly equal to zstd's default level 3, so the zstd command gives a fair preview. It reads all the data once, so run it at a quiet hour:

sudo apt install zstd
sudo tar --create --file=- /etc /home /root /srv /opt /var/www /usr/local /var/backups /var/spool/cron/crontabs | zstd | wc -c | numfmt --to=iec

With --file=-, tar writes to standard output, zstd compresses at level 3, wc -c counts the bytes and numfmt --to=iec prints them like 7.3G. tar's note about the leading / is harmless. Compared with the du total, this shows your compression. gzip's manual says typical text "such as source code or English is reduced by 60-70%"; photos, video and files that are compressed already, such as .gz dumps, barely shrink. borg's default, lz4, is "very fast, but low compression ratio", so expect less unless you pass --compression zstd,N.

Step 3: Count the Copies Your Retention Keeps

The restic guide's policy, --keep-daily 7 --keep-weekly 4 --keep-monthly 12, keeps up to 23 snapshots after a year. restic keeps a few fewer, because one snapshot can match two rules (its docs note that 7 dailies already include a weekly one). In borg, "backups selected by previous rules do not count towards those of later rules", so it keeps 23.

What each kept copy costs depends on the tool:

  • Full archives, such as a nightly tar.gz, store everything again: 23 archives are 23 full copies.
  • restic and borg cut files into chunks by content and store each chunk once, across the whole repository. restic's chunks are 512 KiB to 8 MiB, about 1 MiB on average, and only changed chunks are saved again, which "even works if bytes are inserted or removed at arbitrary positions within the file".

So the repository needs the compressed data once, plus the chunks that differ in each kept snapshot. Space comes back only when old snapshots go: restic forget --prune deletes their data but by default leaves up to 5% unused rather than repacking every partly used file, and borg frees disk space only when borg compact runs after borg prune.

Step 4: Keep the Dumps From Multiplying

Two things make database dumps take far more room than they need.

First, compressed files hardly deduplicate. gzip's manual explains that after a change, compression "can generate a new version of the archive that does not match the previous version of the archive", and pg_dump's custom format (-Fc) is compressed by default. So each night's .dump, .sql.gz or .tar.gz can take up nearly its full size again.

Second, every snapshot holds every file in /var/backups that night, and our PostgreSQL, MariaDB and Docker guides keep 15 nights there (KEEP_DAYS=14). The daily snapshots share most of them, but monthly snapshots are a month apart, so each keeps its own 15 dumps for a year: well over 150 from the monthly snapshots alone.

If restic or borg keeps your history, the server only needs the newest dump:

  • In those scripts, replace -mtime +"$KEEP_DAYS" in the find line with -mmin +720. find then deletes files more than 12 hours old once the new dumps are written, so only tonight's set stays. KEEP_DAYS=0 isn't quite enough: find ignores fractions of a day, so -mtime +0 keeps yesterday's files whenever they're a little under 24 hours old. A failed dump deletes nothing, because set -e stops the script before the find line.
  • Optionally, write uncompressed files and let the backup tool compress them: pg_dump -Fc -Z 0 (level 0 means no compression on PostgreSQL 15 to 18), mariadb-dump without | gzip, tar cf instead of tar czf, and file names to match. Unchanged parts can then be stored once, but the files on the VPS get bigger.

Step 5: A Worked Example

Here is the arithmetic for an imaginary web shop. The numbers are assumptions that show the method, not measurements; use yours from Steps 1 and 2.

  • du on the include list: 10 GB, of which 6 GB product photos and 4 GB code, configs and text.
  • One night's PostgreSQL dump: 2 GB uncompressed. As a worst case, the compressed dumps share no data with each other.
  • Text and SQL shrink by two thirds, in line with gzip's typical figure; photos don't. One full compressed copy is 6 + 1.3 + 0.7 = 8 GB.
  • Retention: 7 daily, 4 weekly and 12 monthly, so up to 23 copies.
SetupWhat the backup storage holdsSize
A: nightly tar.gz of everything, 23 kept23 full copies of 8 GB184 GB
B: restic or borg, 15 nights of compressed dumps on the serverthe files once (7.3 GB), plus roughly 200 different dumps of 0.7 GBroughly 140 to 170 GB
C: restic or borg, only the newest dump on the serverthe files once (7.3 GB), plus at most 23 dumps of 0.7 GBabout 23 GB

B saves little over A, because each monthly snapshot keeps its own 15 or so dumps for a year. C stores at most one dump per kept snapshot, and less with uncompressed dumps, whose unchanged parts are shared.

Then add growth and headroom. If the shop adds 1 GB of photos a month, A stores each new photo in every later archive, up to 23 times, while B and C store it once: C reaches about 35 GB after a year. A 50 GB disk or quota then leaves room for restic's prune, which "requires some scratch space to work", and for borg, whose quickstart asks for "a good amount of free space" on the repository's file system.

Which Setup Fits

  • A few GB and a week of history: nightly tar archives are simple, open on any Linux system and stay small.
  • Months of history: restic or borg, so a year of snapshots costs little more than the data itself.
  • Databases: the backup tool keeps the history and the server only the newest dump, as in setup C.

Check the Real Number After a Week

Your tool's own figures replace the assumptions. restic prints a summary after each backup, and when it runs from the restic guide's timer, systemd sends it to the journal:

sudo journalctl -u restic-backup.service --no-pager | grep 'Added to the repository'

A line such as Added to the repository: 1.200 GiB (1.103 GiB stored) gives the new data after deduplication and, in brackets, after compression: what the repository grew that night. The first night stores almost everything; later nights show your daily change. For the total, load the repository settings in a root shell, as in the restic guide, and run restic stats:

sudo -i
set -a; . /etc/restic/env; set +a
restic stats --mode raw-data

Total Size is what the data of all snapshots takes in the repository; restic 0.16.4 on Ubuntu 24.04 also prints the compression ratio, Debian's 0.14.0 only the total. On the backup machine, du -sh on the repository folder shows the real disk use, including unused data that prune hasn't removed yet. In borg, the This archive line of borg create --stats shows a deduplicated size that the manual calls "how much your repository will grow", and borg info shows it for all archives together.

To project a year, add the typical nightly growth for each day until your oldest snapshots age out. That's an upper bound, because prune removes what only the dropped snapshots used.

Space on the VPS Itself

The server needs room too:

  • The dump files, plus one more set while the next is written, because the scripts write a .part file before deleting old dumps.
  • The cache: sudo du -sh /var/cache/restic for restic, where our guide puts it; borg keeps its cache under /root/.cache/borg when it runs as root.
  • Room to restore: restic stats latest shows what a full restore writes, and our restore drill checks it first.

If the disk is tight, the Space-Node VPS order form offers extra NVMe storage as an add-on, and you can upgrade to a bigger plan from the client area.

Where to Keep the Copies

Not on the same VPS, as the restic guide explains, and ideally in another building. How you pay differs:

  • A second server, storage box or home server over SSH. restic uses SFTP, and borg 1.x repositories are local folders or SSH URLs. You pay for a whole disk, so size it with headroom and watch df -h there.
  • Object storage. restic supports Amazon S3 and S3-compatible services, Backblaze B2, Azure and Google Cloud Storage directly. You pay per GB stored, and often more: Amazon S3's price page lists storage, requests and data retrievals, and data transfer as separate cost components, and bills deleted Standard-IA files for at least 30 days (checked 31 October 2026). Restores download data too, and restic warns that restic check --read-data "might incur higher bandwidth costs than usual".

For the 3-2-1 rule, see our backup strategy guide.

FAQ

Is twice my disk size enough for backups? It can be far off either way. Start from Step 1, not the disk size, since the system and caches don't need backing up. In the example, 10 GB of data needed 184 GB as tar archives and about 23 GB in setup C.

Why didn't my repository shrink after I removed snapshots? restic forget without --prune only removes snapshots; prune deletes their data and leaves up to 5% unused unless you pass --max-unused 0. borg prune frees nothing until borg compact runs; Debian 12 and Ubuntu 24.04 ship borg 1.2, which has it. On a full disk, restic's docs suggest prune --max-repack-size 0 after you forget some snapshots.

Do I need to back up the whole disk? No. Back up settings, data and dumps, and reinstall the system from an image; our checklist before reinstalling lists what to save.

How long should I keep backups? Long enough to cover the time a problem could go unnoticed, such as a deleted folder or a slowly corrupted table. Shorter retention saves the most where data changes a lot: --keep-daily 7 --keep-weekly 4 keeps at most 11 snapshots instead of 23.

Are backups included with a Space-Node VPS? Not in the plan price; you can arrange them through a support ticket.

Sources

All opened on 31 October 2026: