Docs · Notions
Vitesse des sauvegardes
Ce que coûte une sauvegarde de 5 Go en temps, en données envoyées et en ressources du serveur, mesuré le 2026-11-09 avec le vrai agent sur un client à 2 vCPU face au vrai logiciel de stockage. Les chiffres ci-dessous sont des mesures, pas des promesses : votre serveur, vos disques et surtout votre lien réseau font les vôtres.
Ce qui a été mesuré
Mesuré sur le serveur Ikoula partagé, client à 2 vCPU, le 2026-11-09, agent 0.3.0, restic 0.18.1. Un conteneur client jetable (Alpine Linux, PostgreSQL 17) limité à 2 vCPU et 2 Go de RAM a reçu un vrai neverwiped install, puis un échantillon synthétique de 5,3 Go en 50 037 fichiers plus une base :
- 2,1 Go de journaux applicatifs en 32 fichiers (texte, compressible) ;
- 2,0 Go de données aléatoires en 5 fichiers (incompressibles, comme des photos, des vidéos ou des archives) ;
- 1,0 Go en 50 000 petits fichiers JSON de 20 Ko (le coût par fichier d’une sauvegarde) ;
- une base PostgreSQL de 577 Mo, exportée avec
pg_dumpallà chaque sauvegarde comme toute base détectée.
Le stockage (la même passerelle et les mêmes serveurs REST restic qu’en production) tournait sur la même machine, joint par l’interface locale : le lien réseau ne fait pas partie de ces chiffres. Ce qui est mesuré, c’est le travail sur votre serveur (lire, dédupliquer, compresser, chiffrer, exporter la base) et ce qui reste à envoyer une fois ce travail fait. La section plus bas convertit les octets envoyés en minutes pour des liens courants.
Résultats
| Étape | Durée | Données lues | Envoyé au stockage | Dépôt ensuite | CPU / RAM du client (pic) |
|---|---|---|---|---|---|
| Première sauvegarde | 18 s | 5,81 Go, 50 132 fichiers | 3,09 Go | 3,09 Go | 201 % (les deux cœurs) / 380 Mio |
| Deuxième sauvegarde, rien de changé | 3 s | 5,81 Go, 50 132 fichiers | 0,4 Mo | 3,09 Go | trop courte pour être mesurée |
| Troisième sauvegarde, 200 Mo modifiés | 6 s | 5,87 Go, 50 134 fichiers | 210 Mo | 3,30 Go | 128 % / 368 Mio |
| Restauration complète dans un nouveau dossier | 10 s | 5,87 Go écrits | — | — | 161 % / 542 Mio |
Les 200 Mo modifiés étaient 150 Mo réécrits dans l’un des fichiers aléatoires plus un nouveau fichier texte de 50 Mo ; la base n’a pas bougé et son export a quand même été refait, d’où les 5,87 Go lus. Après la restauration, le SHA-256 de chaque fichier et une réimportation de la base correspondaient aux originaux.
Côté stockage, la passerelle est restée sous 13 % d’un cœur et 10 Mio de RAM pendant la première sauvegarde ; le serveur REST restic derrière elle sous 22 % et 104 Mio. La génération de l’échantillon (54 s sur l’hôte) n’est pas comptée.
Ce que disent ces chiffres :
- La première sauvegarde dépend de vos données et de votre lien. 5,81 Go lus, 3,09 Go envoyés : les journaux, les petits fichiers et l’export de la base se sont bien compressés, les 2 Go aléatoires non. Avec deux cœurs à fond, le serveur a traité environ 320 Mo/s ; un disque plus lent ou
neverwiped limits --limit-cpus 1baisse ce chiffre. - Une nuit sans changement coûte quelques secondes. L’agent relit la liste des fichiers et réexporte la base, puis n’envoie presque rien (0,4 Mo de métadonnées).
- Une nuit avec des changements coûte les changements. 200 Mo modifiés, 210 Mo envoyés, en 6 s de traitement.
- La restauration est rapide côté serveur : 5,87 Go écrits en 10 s. Sur un vrai lien, c’est le téléchargement des 3,3 Go stockés qui donne le rythme.
À quoi s’attendre sur votre lien
Le temps de traitement ci-dessus est le plancher ; l’envoi est en général le plafond. Arithmétique à partir des octets envoyés (sans marge, lien stable supposé) :
| Lien (envoi) | Première sauvegarde, 3,09 Go envoyés | Troisième sauvegarde, 210 Mo envoyés | Restauration, 3,3 Go récupérés |
|---|---|---|---|
| 1 Gbit/s (125 Mo/s) | environ 25 s | 2 s | environ 27 s |
| 100 Mbit/s (12,5 Mo/s) | environ 4 min 10 s | 17 s | environ 4 min 25 s |
| 20 Mbit/s (2,5 Mo/s) | environ 21 min | 1 min 25 s | environ 22 min |
Une première sauvegarde de 50 Go de données mixtes enverrait en gros 25 à 30 Go : environ 35 minutes à 100 Mbit/s, environ 3 heures à 20 Mbit/s. L’installation affiche une estimation pour votre propre plan avant tout envoi, et neverwiped limits --limit-upload garde le lien utilisable pendant ce temps (la première sauvegarde dure alors plus longtemps ; une exécution planifiée est arrêtée après 12 heures, retirez donc la limite pour une très grosse première sauvegarde).
En une phrase
Sur notre serveur de test à 2 vCPU, une première sauvegarde d’un échantillon de 5 Go a demandé 18 secondes de traitement et envoyé 3,1 Go après compression et déduplication, soit environ quatre minutes sur un lien à 100 Mbit/s ; la nuit suivante, sans changement, 3 secondes ; avec 200 Mo modifiés, 6 secondes et 210 Mo envoyés.
Reproduire la mesure
La mesure est un script du dépôt de l’agent (scripts/speed-report.sh) : il démarre la pile de stockage et un remplaçant de la plateforme sur une machine, installe l’agent dans un conteneur client à 2 vCPU avec l’échantillon ci-dessus, chronomètre les trois sauvegardes et la restauration, vérifie chaque somme de contrôle, affiche le tableau et supprime tout. La date en haut de cette page dit quand il a tourné pour la dernière fois.