Docs · Concepts
Backup speed
What a backup of 5 GB costs in time, data sent and server resources, measured on 2026-11-09 with the real agent on a 2 vCPU client against the real storage software. The figures below are measurements, not promises: your server, your disks and above all your network link set your own.
Markdown versionThe CLI prints English by default (`--lang fr|es` for French or Spanish). Some output blocks come from a French session: they are labelled and translated in the text.
What was measured
Measured on the shared Ikoula server, 2 vCPU client, on 2026-11-09, agent 0.3.0, restic 0.18.1. A throwaway client container (Alpine Linux, PostgreSQL 17) capped at 2 vCPU and 2 GB of RAM received a real neverwiped install, then a synthetic sample of 5.3 GB in 50 037 files plus a database:
- 2.1 GB of application logs in 32 files (text, compressible);
- 2.0 GB of random data in 5 files (incompressible, like photos, videos or archives);
- 1.0 GB in 50 000 small JSON files of 20 KB (the per-file cost of a backup);
- a 577 MB PostgreSQL database, exported with
pg_dumpallat every backup like any detected database.
The storage (the same gate and restic REST servers as in production) ran on the same machine, reached over the loopback interface: the network link is not part of these numbers. What is measured is the work on your server (reading, deduplicating, compressing, encrypting, exporting the database) and what is left to send once that work is done. The section below turns the bytes sent into minutes for common links.
Results
| Phase | Wall time | Data read | Sent to the storage | Repository after | Client CPU / RAM (peak) |
|---|---|---|---|---|---|
| First backup | 18 s | 5.81 GB, 50 132 files | 3.09 GB | 3.09 GB | 201 % (both cores) / 380 MiB |
| Second backup, nothing changed | 3 s | 5.81 GB, 50 132 files | 0.4 MB | 3.09 GB | too short to sample |
| Third backup, 200 MB changed | 6 s | 5.87 GB, 50 134 files | 210 MB | 3.30 GB | 128 % / 368 MiB |
| Full restore to a new folder | 10 s | 5.87 GB written | — | — | 161 % / 542 MiB |
The 200 MB change was 150 MB overwritten inside one of the random files plus a new 50 MB text file; the database was left as it was and its export was still redone, which is why 5.87 GB were read. After the restore, the SHA-256 of every file and a re-import of the database matched the originals.
On the storage side, the gate stayed under 13 % of one core and 10 MiB of RAM during the first backup; the restic REST server behind it under 22 % and 104 MiB. The sample itself took 54 s to generate on the host and is not counted.
What these numbers say:
- The first backup is dominated by your data and your link. 5.81 GB were read and 3.09 GB sent: the logs, the small files and the database export compressed well, the 2 GB of random data did not. With two cores fully used, the server processed about 320 MB/s; a slower disk or
neverwiped limits --limit-cpus 1lowers that. - A night with no change costs seconds. The agent still reads the file list and re-exports the database, then sends about nothing (0.4 MB of metadata).
- A night with changes costs the changes. 200 MB changed, 210 MB sent, in 6 s of processing.
- Restore is fast on the server side: 5.87 GB written in 10 s. On a real link, the download of the 3.3 GB stored sets the pace.
What to expect on your link
The processing time above is the floor; the upload is usually the ceiling. Arithmetic from the bytes sent (no safety margin, a steady link assumed):
| Link (upload) | First backup, 3.09 GB sent | Third backup, 210 MB sent | Restore, 3.3 GB fetched |
|---|---|---|---|
| 1 Gbit/s (125 MB/s) | about 25 s | 2 s | about 27 s |
| 100 Mbit/s (12.5 MB/s) | about 4 min 10 s | 17 s | about 4 min 25 s |
| 20 Mbit/s (2.5 MB/s) | about 21 min | 1 min 25 s | about 22 min |
A first backup of 50 GB of mixed data would send roughly 25 to 30 GB: about 35 minutes at 100 Mbit/s, about 3 hours at 20 Mbit/s. The install shows an estimate for your own plan before anything is sent, and neverwiped limits --limit-upload keeps the link usable while it runs (the first backup then takes longer; a scheduled run is stopped after 12 hours, so remove the limit for a very large first backup).
In one sentence
On our 2 vCPU test server, a first backup of a 5 GB sample took 18 seconds of processing and sent 3.1 GB after compression and deduplication, about four minutes on a 100 Mbit/s link; the next night, with nothing changed, it took 3 seconds; with 200 MB changed, 6 seconds and 210 MB sent.
Reproduce it
The measurement is a script in the agent's repository (scripts/speed-report.sh): it starts the storage stack and a stand-in for the platform on one machine, installs the agent in a 2 vCPU client container with the sample above, times the three backups and the restore, verifies every checksum, prints the table and removes everything. The date at the top of this page says when it last ran.