How much storage VPS do you actually need?

The short answer

A storage VPS is sized from your own data, not from a price list. Measure what you keep live, work out how large the backup repository becomes under the retention you want, add the growth you expect over the next two years, then divide the total by 0.8 so the filesystem never runs to the edge. That last division is the step most people skip, and it is why a 2 TB plan bought in January is full in September.

The number that surprises people is the backup repository. Its size follows your retention policy, not the size of your source data. In the worked model below, a source that never grows past 500 GB fills 2690 GB of repository once you ask for three years of history. Nothing was added to the source. You only asked to keep more versions of it.

Everything here is expressed in euros per terabyte per month, because that is the only figure that compares a rented server against a managed storage box or against a NAS (network attached storage) in your own flat. The DSGVO section at the end matters more than it looks, since most of this data turns out to be photographs of other people. If you are still deciding whether a storage VPS or a regular VPS is the right product, settle that first. This guide answers the next question: how many terabytes, and what they cost.

Step 1: measure what you already have

Do not estimate. Measure.

sudo du -x -h -d 1 /srv | sort -h
sudo ncdu -x /srv
df -h /srv

du -x stays on one filesystem, so a separate backup volume mounted under /srv is not counted twice. ncdu shows the same data as a browsable list, which is faster when you are hunting for the one directory holding 400 GB of forgotten video. df reports what the filesystem thinks it has. When df and du disagree by a lot, some process is holding a deleted file open, sudo lsof +L1 lists those files, and the space comes back when that process restarts.

Then correct the figure for what your applications add on top of the originals. Immich keeps the original file and generates thumbnails, plus transcoded copies of videos. Plan for 10 to 25 percent above the size of the originals, which is the range these libraries usually land in, and measure yours once it runs. What Immich needs in RAM and disk scales with the library rather than with the number of users. Those derived files can be regenerated from the originals, so keep them out of the backup set and count them only as live capacity.

Nextcloud is the other quiet multiplier. It keeps a trash bin and a version history for every file, and both live inside the same data directory, so a 120 GB share occupies more on disk than the sum of what the users see. Set trashbin_retention_obligation and versions_retention_obligation in config.php before you size anything, and confirm where a Nextcloud Docker install actually keeps its files, because it is often not the path the compose file suggests.

Step 2: why the backup repository is not the size of your data

restic splits files into content-addressed chunks. A file that appears in a hundred snapshots is stored once. A file whose last few kilobytes changed is not stored again in full, because only the changed chunks are written. restic also compresses chunks when the repository uses format version 2, so check yours with restic -r <repo> cat config and read the version field, then upgrade an older repository with restic migrate upgrade_repo_v2. Compression does nothing for photographs and video, which are compressed already, and a great deal for text and database dumps.

Ask the repository instead of guessing.

restic -r sftp:backup@storage.example.net:/srv/restic stats --mode raw-data
restic -r sftp:backup@storage.example.net:/srv/restic stats latest --mode restore-size

--mode raw-data reports what the repository occupies after deduplication and compression. --mode restore-size against latest reports how much you would write to disk restoring the newest snapshot. The gap between those two numbers is what your history costs. On the server itself, du -sh /srv/restic is the ground truth, and it should track the raw-data figure closely. If the repository does not exist yet, the restic setup on a VPS takes about twenty minutes, and then you are sizing from a measurement instead of from a guess.

How much does retention cost you in gigabytes?

Take a source of 500 GB where 2 GB of content is replaced every day, with the replaced content deleted and never returning. The repository then holds the current 500 GB plus everything that was still current at the oldest snapshot you keep. Repository size follows the age of that oldest snapshot.

[
  {
    "label": "7 days of history",
    "repo_gb": 514
  },
  {
    "label": "35 days of history",
    "repo_gb": 570
  },
  {
    "label": "1 year of history",
    "repo_gb": 1230
  },
  {
    "label": "3 years of history",
    "repo_gb": 2690
  }
]

Those rows are arithmetic from the assumptions in the paragraph above, not a measurement of your data. The shape is the lesson. 514 GB buys a week of history and costs almost nothing over a single copy. 570 GB buys five weeks. 1230 GB buys a year. 2690 GB buys three years, more than five times the source, for versions you will almost certainly never restore.

One year of history is one command.

restic -r sftp:backup@storage.example.net:/srv/restic forget \
  --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune

forget removes the snapshots. --prune is the half that frees space, because without it the data stays in the repository and du -sh does not move. Run this on a schedule. A repository that is never pruned grows forever, and the first sign is usually a full disk.

Data that is rewritten in place behaves worse than the model. A database dumped nightly into one compressed file defeats deduplication completely, because a compressed stream changes from the first differing byte to the end, so restic sees a brand new file every night and stores it whole. Dump uncompressed, or use gzip --rsyncable, and let restic do the compressing. That one change decides whether a year of nightly dumps costs you roughly one copy of the database or one copy per retained snapshot.

A worked example: photos, documents and a small server

A freelance photographer near Stuttgart has four piles of data. Client and family photographs, a Nextcloud share of contracts and invoices, a ripped film library, and the volumes of a small VPS running Nextcloud with its database. Only some of it belongs on rented disks.

[
  {
    "label": "Photo library (RAW and JPEG)",
    "source_gb": 900,
    "backup_gb": 930
  },
  {
    "label": "Nextcloud documents share",
    "source_gb": 120,
    "backup_gb": 190
  },
  {
    "label": "Film and series library",
    "source_gb": 2000,
    "backup_gb": 0
  },
  {
    "label": "Server volumes and databases",
    "source_gb": 200,
    "backup_gb": 340
  }
]

Read the second column against the first. The film library is 2000 GB of source and 0 GB of backup, because the discs are still on the shelf and a re-rip costs a weekend rather than a client. Photographs go from 900 GB live to 930 GB stored, almost nothing added, because photographs are written once and never edited in place. The documents share goes the other way, from 120 GB live to 190 GB stored, because those files are edited every working day and a year of history keeps a version of each. Server volumes and databases have the worst ratio of the lot, 200 GB live against 340 GB stored.

Decide what belongs in the backup set before you size anything. Data you can recreate does not belong there, and every gigabyte you exclude is a gigabyte you do not rent every month for the next five years.

The arithmetic that sizes a storage VPS

[
  {
    "label": "Backup repository today",
    "gb": 1460
  },
  {
    "label": "Growth over 24 months",
    "gb": 400
  },
  {
    "label": "Data at month 24",
    "gb": 1860
  },
  {
    "label": "Headroom to stay at 80 percent",
    "gb": 465
  },
  {
    "label": "Capacity to buy",
    "gb": 2325
  }
]

Read it top to bottom. The repository today is 1460 GB, the sum of the backup column above. Growth over the next 24 months is 400 GB, from roughly 15 GB of new photographs a month plus slow creep everywhere else. That gives 1860 GB of data at month 24. Divide by 0.8 and the capacity to buy is 2325 GB, of which 465 GB is headroom you deliberately never fill.

Measure your growth rather than guessing it. Compare today's du output against the same figure from a year ago if you kept one, or record it weekly for a month and multiply. A guessed growth rate is the reason plans get outgrown quietly.

2325 GB does not fit a 2 TB plan. Advertised terabytes are decimal, so 2 TB is 2000 GB before the filesystem takes its own overhead, and the headroom rule has already been applied to the figure. The honest choice is the next tier up, or a shorter retention policy that pulls the requirement below 2000 GB. Storage tiers roughly double, so sizing almost always lands between two of them, and the real question is which of the two you can defend for the length of the contract.

Two adjustments before you buy. This capacity is the offsite copy, so treating a rented server as your offsite backup target means the copy at home is a separate purchase with its own arithmetic. And if the data matters enough for two independent copies, a second restic repository at another provider doubles this number rather than adding a little to it, because the second repository deduplicates only against itself.

The capacity a provider advertises for a storage VPS is usable capacity, already behind whatever redundancy they run. On hardware you buy yourself, that redundancy comes out of your own pocket: RAID 10 hands back half the raw terabytes, and a two-disk mirror hands back half as well. Compare usable against usable.

Why you must not fill the disk

The 0.8 divisor is not caution. It is the point where filesystems and backup tools start behaving differently.

Copy-on-write filesystems, ZFS and btrfs, never overwrite a block in place, so every write needs a new location. When the pool is nearly full, the allocator spends its time searching for one, and write latency climbs long before the pool is actually full. Keep a ZFS pool at or below 80 percent.

restic prune needs room to work. It repacks partially used pack files, which means writing new files before it deletes the old ones. On a full repository prune fails, and the obvious fix, deleting snapshots to free space, is exactly the operation that will not run. The escape is restic prune --max-repack-size 0, which deletes fully unused pack files and skips the repacking, so it frees space with almost no scratch space of its own.

ext4 reserves 5 percent of the filesystem for root by default. On a 4 TB data volume that is 200 GB you are paying for and cannot use.

sudo tune2fs -l /dev/vdb1 | grep -i 'reserved block count'
sudo tune2fs -m 1 /dev/vdb1
zpool list -o name,size,alloc,free,capacity
df --output=pcent,target /srv/restic

Cutting the reserve to 1 percent is safe on a dedicated data volume. Never do it on the root filesystem, because that reserve is what lets root log in and clean up when the disk fills.

A full volume fails loudly and everywhere at once. Writes return No space left on device, the backup aborts and the database stops accepting writes. On ZFS it is worse, because deleting a file is itself a write, and a pool at 100 percent can refuse the deletion that would fix it. Alert at 80 percent rather than at 95, so you are buying the next tier on a Tuesday afternoon instead of at three in the morning.

What does a terabyte cost per month, in euros?

Convert every candidate to euros per terabyte per month before you compare anything else. Take the monthly price, divide by the advertised terabytes. Plans are bundled differently and the headline price hides the rate.

Do not carry a price out of an article, including this one. Providers change their tiers, and a figure that was right in August 2026 is a starting point rather than a quote. What survives is the arithmetic.

Do the same division on the NAS, because that is the comparison most readers actually make. Take a two bay enclosure with two 8 TB drives in a mirror. If the hardware costs 600 euros (plausible as of August 2026, check today's shop prices) and lasts five years, that is 10 euros a month. Add power. Two spinning disks and the enclosure draw about 25 W, so 25 W over 24 hours and 365 days is 219 kWh a year, and at 0.35 euros per kWh (a typical German household rate as of August 2026, check your own tariff) that is about 77 euros a year, or 6.40 euros a month. The mirror leaves 8 TB usable. The total is about 16.40 euros a month, near 2.05 euros per terabyte per month.

That rate looks unbeatable until you notice what it does not buy. The NAS stands in the same flat as the computer it protects, so one fire, one burglary, one water leak, or one ransomware infection that reaches the SMB share takes both copies in the same minute. Compare the NAS against your local disk. Compare the rented server against the offsite copy you need anyway, which the NAS is not. The same division applied to a Dropbox subscription is worth doing while the spreadsheet is still open.

A managed storage box is the other honest comparison. It is usually the lowest euros per terabyte on the market, because it only stores. You get SFTP, rsync, WebDAV and often a Borg or restic endpoint, and no shell. That is enough to be a backup target and not enough to run anything. The moment you want the same disks to also serve a photo gallery, you are buying a server. The per-terabyte gap between a storage VPS, block storage and object storage is wide enough that the product choice usually moves the bill more than the capacity choice does.

Then check what the rate excludes. Traffic is the usual surprise: restoring 1.5 TB is 1.5 TB of egress, and a plan with a monthly transfer allowance can turn a restore into an invoice. Ask what happens when the allowance runs out, and ask before the restore rather than during it.

Does "EU" on the datasheet mean Germany?

No. "EU" covers Amsterdam, Paris, Helsinki and Warsaw as comfortably as it covers Frankfurt, and some providers can move a region with little notice. If a contract or a customer requires Germany, the word on the datasheet is not enough. Check it in this order.

1. Ask support in writing for the city and the facility, and keep the reply. This is the only check with legal weight.
2. Read the order page for a named region, then read the terms for whether that region can change later.
3. Look up the IP block with whois -h whois.ripe.net 203.0.113.10. The country: field describes the registration, not the rack, so treat it as a hint.
4. Measure the latency. Distance sets a floor of roughly 1 ms of round trip per 100 km of fibre, and fibre never runs straight, so a server that answers a German consumer line in 6 ms is not sitting in Helsinki.

mtr -rwc 20 storage.example.net
ping -c 20 storage.example.net

IP geolocation databases are frequently wrong for hosting ranges, because a provider can register a block in one country and route it in another. Latency proves the disks are near you. It cannot prove which building they are in, and only the written answer does that. If Germany is the requirement, a VPS in a Frankfurt datacentre is the usual answer, since Frankfurt carries DE-CIX and most German providers have racks in the city. If your users sit further east, a Polish location is physically closer to them, though it is a different jurisdiction and belongs in your records as such.

DSGVO: these are other people's photos

The DSGVO (Datenschutz-Grundverordnung, the German name for the GDPR, the General Data Protection Regulation) applies to personal data. A photograph of an identifiable person is personal data. So is an invoice carrying a name, and so is the Nextcloud share you gave a colleague. This section is orientation, not legal advice. If client data is involved, ask a lawyer or your Datenschutzbeauftragter (data protection officer).

Renting the disks changes four things.

1. The household exemption. Article 2(2)(c) excludes purely personal or household activity, so the family album is covered. The moment you store a client's wedding shoot for money, it is not.
2. The AVV. A provider storing your data on your instruction is an Auftragsverarbeiter (processor), and Article 28 requires a written contract, called an Auftragsverarbeitungsvertrag (AVV) in German. Serious providers publish theirs and let you sign it in the control panel. Get it before you upload, not after.
3. The location. Storing inside the EU avoids the transfer question in Article 44 and following. Where the company is registered is a separate question from where the disks spin, and both belong in your records.
4. The deletion path. Article 17 gives people a right to erasure, and a backup system is built to resist deletion. Work out how you would remove one person's files before someone asks you to.

Deletion is the part that catches people, so be concrete. Removing a file from the source does nothing to the repository, because every snapshot that referenced it still references it. Removing it for real takes two steps.

restic -r sftp:backup@storage.example.net:/srv/restic rewrite \
  --exclude '/srv/data/clients/mueller/**' --dry-run
restic -r sftp:backup@storage.example.net:/srv/restic rewrite \
  --exclude '/srv/data/clients/mueller/**' --forget
restic -r sftp:backup@storage.example.net:/srv/restic prune

rewrite writes new snapshots without the excluded paths and --forget drops the originals, but the chunks stay in the repository until prune runs, because rewrite only changes what is referenced. Start with --dry-run and read the list of snapshots it would touch. Afterwards, confirm with restic stats --mode raw-data that the repository actually shrank.

Encryption is the strongest technical measure you control here. A restic repository is encrypted on your own machine before anything is uploaded, using AES-256 in counter mode with a Poly1305-AES message authentication code, so the provider holds ciphertext it cannot read. That counts for a great deal under Article 32, and it does not replace the AVV, because the provider is still storing and hosting personal data.

Ask one more question before you sign. How long does the provider keep its own snapshots and backups of your volume? Those are copies of the same personal data that you cannot prune and did not schedule. A provider snapshot is a rollback feature, not a backup you can rely on, so keep it out of your capacity plan and inside your deletion documentation.

A sizing checklist you can run today

1. Run sudo ncdu -x / on every machine holding data, and write down each directory over 10 GB.
2. Decide which of those directories go into the backup set. Anything you can recreate stays out.
3. Pick a retention policy and price it. A year of history is the common answer.
4. Run restic stats --mode raw-data if a repository already exists. If not, budget the source size plus about 50 percent for data that is edited daily, and plus about 5 percent for photographs and video.
5. Add the growth you have actually measured over the last twelve months.
6. Divide the total by 0.8.
7. Convert every candidate plan to euros per terabyte per month, and put the traffic allowance into the same comparison.
8. Get the datacentre city in writing, and get the AVV, if any of the data belongs to other people.

FAQ

How many terabytes do I need for a 1 TB photo library?

About 2.75 TB if the same server both serves the library and holds its backup. Work it through: 1000 GB of originals, plus roughly 15 percent for the thumbnails and transcodes a gallery like Immich generates, gives about 1150 GB live. A year of restic history over the originals adds very little, because photographs are written once and never edited, so the repository lands near 1050 GB. That is about 2200 GB of data, and dividing by 0.8 for headroom gives about 2750 GB. If the server only holds the backup and the library lives at home, 1.3 TB is enough.

Why is my restic repository bigger than the data I back up?

Because the repository holds every version that a retained snapshot still references. Deduplication removes the parts that are identical between snapshots. It cannot remove the parts that changed. A file rewritten every day contributes new chunks on every run, and those chunks stay until the last snapshot pointing at them is forgotten and pruned. Run restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune, then compare restic stats --mode raw-data before and after. If the number does not move, the --prune flag was missing and only the snapshot entries were deleted.

How full can I let the disk on a storage VPS get?

Eighty percent is the working limit. Above it, copy-on-write filesystems such as ZFS and btrfs slow down as the allocator hunts for free space, and restic prune loses the scratch space it needs to repack pack files. A completely full volume is worse than slow: writes fail with No space left on device, and on a ZFS pool at 100 percent even deleting a file can fail, because the deletion is itself a write. If you are already stuck there, restic prune --max-repack-size 0 frees whole unused pack files without repacking anything.

Does an EU datacentre mean my data is in Germany?

No. "EU" on a datasheet covers Amsterdam, Paris, Helsinki and Warsaw as much as it covers Frankfurt, and a provider may place a region wherever it has capacity. Ask support in writing for the city and the facility, and keep the reply with your processing records, because that answer is the only one with legal weight. whois -h whois.ripe.net <ip> shows the registered country of the IP block, which is a hint rather than proof, and round trip latency gives a physical floor of roughly 1 ms per 100 km of fibre.

Is a NAS at home cheaper than a storage VPS?

Per terabyte, usually yes. A two bay NAS with two 8 TB drives in a mirror, at 600 euros of hardware spread over five years plus about 25 W of continuous power, works out near 16 euros a month for 8 TB usable, or roughly 2 euros per terabyte per month (figures as of August 2026, check today's prices and your own electricity tariff). It is a different product though. The NAS stands in the same building as the machine it protects, so a fire or ransomware reaching the local network can take both copies at once. A NAS replaces your local disk. A rented server replaces the offsite copy you do not otherwise have.