Utiliser un VPS comme cible de sauvegarde externalisée

Ce qu’est réellement une cible de sauvegarde externalisée

Une cible de sauvegarde externalisée est une seconde machine qui conserve une copie de vos données et qui tombe en panne indépendamment du serveur d’origine. Pour la plupart des lecteurs, un VPS chez un autre fournisseur est l’option la moins coûteuse. Trois architectures sont réalistes : Proxmox Backup Server installé sur le VPS, un dépôt restic accessible via SSH ou S3, ou un miroir rsync récupéré par l’hôte de sauvegarde. Le choix dépend de ce que vous devez restaurer et du délai acceptable pour remettre le service en ligne. Le contrôle des droits de suppression de la copie est le facteur déterminant.

Externalisée signifie dans un autre domaine de panne. Il faut donc un autre fournisseur et un compte qui ne partage aucun identifiant avec celui qui exécute votre serveur. Un second serveur dans une autre région du même fournisseur résiste à un incendie dans un bâtiment. Il ne résiste pas à la compromission des identifiants du panneau de contrôle, car un même compte contrôle les deux copies.

Un snapshot chez votre fournisseur ne constitue pas cette seconde copie. Il reste protégé par le même mot de passe du panneau de contrôle. Toute personne qui obtient ce mot de passe peut supprimer le serveur et ses snapshots au cours de la même session. Les services de snapshots facturent également chaque gigaoctet et chaque mois à des tarifs bien supérieurs à ceux d’un simple disque, ce qui rend leur conservation pendant 90 jours coûteuse. La différence entre les snapshots VPS et les sauvegardes mérite d’être lue avant de vous fier à l’une ou l’autre solution.

Quelle forme vous convient

• Proxmox Backup Server (PBS) : la source est Proxmox VE (environnement virtuel) et l’élément restauré est une machine virtuelle complète. Il effectue les sauvegardes au niveau de l’image disque, et ses tâches de vérification relisent les données présentes sur la cible.
• Un dépôt restic : la source est un ou plusieurs hôtes Linux et l’élément restauré est un répertoire ou un dump de base de données. Le chiffrement est effectué côté client. restic prend en charge SSH et S3, ainsi que son propre protocole REST.
• rsync over SSH, exécuté depuis l’hôte de sauvegarde : vous voulez que les fichiers présents sur la cible restent des fichiers ordinaires, lisibles avec ls et cat, sans devoir installer de logiciel client pour les récupérer.

Si vous ne parvenez pas à choisir, utilisez restic. Le chiffrement est effectué avant toute sortie de la machine. La cible n’a besoin que d’un compte SSH et d’espace disque. Configurer des sauvegardes restic sur un VPS présente plus en détail la configuration côté client. restic et BorgBackup comparés explique le choix si vous utilisez déjà Borg.

Dimensionner la cible : coût d’un mois de rétention

La déduplication explique pourquoi les chiffres sont inférieurs aux prévisions. restic et PBS découpent les fichiers en blocs de taille variable et calculent le hash de chaque bloc. Chaque bloc unique n’est stocké qu’une seule fois. La deuxième sauvegarde d’un jeu de données de 500 GB n’ajoute donc pas 500 GB supplémentaires. Elle ajoute uniquement les blocs qui ont changé.

La taille du repository dépend donc de l’ancienneté du snapshot le plus ancien, et non du nombre de snapshots. Prenons 500 GB de données et 5 GB de nouvelles données uniques par jour. Le repository contient alors les 500 GB initiaux, plus environ 5 GB pour chaque jour séparant le snapshot le plus ancien conservé par la policy de la date actuelle.

[
  {
    "label": "7 daily",
    "repo_size_gb": 535,
    "usd_at_10_per_tb": 5.35
  },
  {
    "label": "7 daily, 4 weekly",
    "repo_size_gb": 640,
    "usd_at_10_per_tb": 6.4
  },
  {
    "label": "7 daily, 4 weekly, 6 monthly",
    "repo_size_gb": "1,400",
    "usd_at_10_per_tb": 14.0
  },
  {
    "label": "7 daily, 4 weekly, 12 monthly",
    "repo_size_gb": "2,325",
    "usd_at_10_per_tb": 23.25
  }
]

La colonne en dollars chiffre ce repository à 10 dollars US par TB et par mois. Il s’agit d’une valeur indicative pour effectuer le calcul, et non du tarif d’un provider. Remplacez-la par le prix réel par TB du plan que vous envisagez. Une semaine de sauvegardes quotidiennes occupe environ 535 GB. Une année complète d’historique occupe 2,325 GB, soit $23.25 par mois, contre $5.35 pour une semaine. L’historique coûte peu. Vous payez principalement pour la copie de base.

La déduplication n’est d’aucune utilité pour les données qui arrivent déjà compressées ou chiffrées. Un dump de base de données compressé avec gzip change complètement à chaque exécution. Chaque dump est donc enregistré sous forme de nouveaux blocs, et le repository augmente de la taille complète d’un dump chaque nuit. Écrivez le dump sans compression et laissez l’outil de sauvegarde le compresser, car restic prend en charge les repository compressés depuis 0.14 et la version 0.19 a ajouté les modes zstd fastest et better. Les bibliothèques de photos et de vidéos se dédupliquent mal pour la même raison. Dimensionnez-les à partir de leur croissance réelle plutôt qu’à partir des lignes ci-dessus.

Vous achetez ici principalement de l’espace disque inutilisé, et non du CPU. C’est précisément le cas où un storage VPS est plus intéressant qu’un VPS classique.

Pourquoi la bande passante et le temps de restauration déterminent le plan

Le disque est la partie la moins chère. Le premier upload et la restauration éventuelle sont les opérations coûteuses. 500 GB représentent 4 trillion de bits. La division par le débit de la liaison donne donc la durée minimale d’une restauration complète.

[
  {
    "label": "40 Mbit/s home upload",
    "elapsed_h": 27.8
  },
  {
    "label": "100 Mbit/s",
    "elapsed_h": 11.1
  },
  {
    "label": "500 Mbit/s",
    "elapsed_h": 2.2
  },
  {
    "label": "1 Gbit/s VPS port",
    "elapsed_h": 1.1
  }
]

Ces chiffres correspondent au débit nominal, sans surcharge liée aux protocoles. Considérez-les comme un cas idéal. À 100 Mbit/s, une restauration complète nécessite 11.1 heures avant même que quelqu’un puisse accéder aux données. Avec un débit montant domestique de 40 Mbit/s, elle nécessite 27.8 heures. Sur un port à 1 Gbit/s, la même restauration prend 1.1 heures. Un grand nombre de petits fichiers ralentit l’opération par rapport au calcul théorique, car la surcharge par fichier devient prépondérante lorsque les fichiers font moins de quelques centaines de kilooctets.

Deux conséquences en découlent. Si votre objectif de délai de reprise (RTO), c’est-à-dire la durée d’interruption que vous pouvez tolérer, est de quatre heures, une restauration de 500 GB sur une liaison à 100 Mbit/s dépasse déjà ce délai. Un disque moins cher ne change rien. La plupart des offres VPS facturent aussi le trafic sortant. Une seule restauration complète consomme donc 0.5 TB du quota mensuel de l’hôte de sauvegarde. Vérifiez ce quota ainsi que les mesures appliquées par le fournisseur lorsque vous le dépassez, avant d’avoir besoin des données.

La première sauvegarde contient l’ensemble du dataset. C’est l’exécution la plus longue que vous aurez à effectuer. Lancez-la un vendredi et limitez son débit pour éviter de saturer la liaison montante de la source : restic accepte --limit-upload en KiB par seconde, et rsync accepte --bwlimit.

Forme 1 : Proxmox Backup Server comme datastore distant

PBS convient lorsque la source est Proxmox VE et que l’unité restaurée est une machine virtuelle. Un VPS ne peut pas démarrer l’ISO Proxmox. Installez donc PBS par-dessus Debian. La version 4.2 est la version actuelle en août 2026 et repose sur Debian 13 (trixie).

wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg \
  -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

Comparez cette somme de contrôle à la valeur publiée sur la page des dépôts de paquets Proxmox. La fiabilité d’un dépôt apt dépend entièrement de la clé que vous avez vérifiée. Écrivez ensuite /etc/apt/sources.list.d/proxmox.sources :

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update && sudo apt install -y proxmox-backup-server
sudo proxmox-backup-manager datastore create offsite /mnt/datastore/offsite

Attribuez au datastore son propre système de fichiers ou son propre volume. Un datastore plein arrête les sauvegardes. Un datastore qui partage le système de fichiers racine peut faire tomber tout le serveur lorsqu’il est saturé.

Créez ensuite le compte que la source utilisera et attribuez-lui un token plutôt qu’un mot de passe.

sudo proxmox-backup-manager user create backup@pbs
sudo proxmox-backup-manager user generate-token backup@pbs pve1
sudo proxmox-backup-manager acl update /datastore/offsite DatastoreBackup \
  --auth-id 'backup@pbs!pve1'

Le secret du token s’affiche une seule fois et ne peut pas être relu. Enregistrez-le dès qu’il apparaît. Le rôle est aussi important que le token. DatastoreBackup peut créer et restaurer ses propres sauvegardes. Il ne possède pas le privilège Datastore.Prune. Ce token ne peut donc pas supprimer un snapshot qu’il a déjà écrit.

La rétention sur PBS comporte deux volets, et le second est souvent ignoré. Le prune supprime les snapshots. Le garbage collection supprime les chunks auxquels aucun snapshot conservé ne fait plus référence. L’espace libre apparaît après le garbage collection, et non après le prune.

proxmox-backup-client prune host/web1 \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run
sudo proxmox-backup-manager garbage-collection start offsite
sudo proxmox-backup-manager verify offsite

Supprimez --dry-run lorsque la liste des snapshots qu’il prévoit de supprimer vous convient. Le garbage collection s’exécute en deux phases. Il met à jour l’heure d’accès de chaque chunk encore référencé, puis supprime les chunks dont l’heure d’accès est antérieure à la limite. Cette limite se situe 24 heures et 5 minutes avant le début de l’exécution. Ce délai de grâce empêche la suppression d’un chunk encore écrit par une sauvegarde en cours. Planifiez un prune quotidien et un garbage collection hebdomadaire sur le datastore. Ajoutez également un verify job afin que la cible relise ses propres chunks et signale une corruption sur le disque avant qu’une restauration ne la révèle.

Si la source est elle-même une instance PBS, le serveur distant peut effectuer un pull au lieu de recevoir un push.

sudo proxmox-backup-manager remote create home1 \
  --host pbs.home.example --userid sync@pam --password 'SECRET' \
  --fingerprint '64:d3:ff:3a:50:38:53:5a:9b:f7:50:ab:fe'
sudo proxmox-backup-manager sync-job create home1-offsite \
  --remote home1 --remote-store main --store offsite --schedule 'Wed 02:30'

Exécutez ce sync job sur le VPS, dans le sens de pull par défaut. Le VPS accède au datastore principal. Le serveur principal ne détient donc aucun identifiant capable de modifier la copie distante.

Forme 2 : un dépôt restic via SSH ou S3

Debian et Ubuntu fournissent tous deux restic, mais leurs versions sont en retard sur la version amont. La version 0.19.1 est la version actuelle en août 2026. Installez le binaire officiel sur l’hôte source.

curl -LO https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2
bunzip2 restic_0.19.1_linux_amd64.bz2
sudo install -m 755 restic_0.19.1_linux_amd64 /usr/local/bin/restic
restic version

restic version affiche la version et le compilateur Go utilisé pour la compilation. Les mises à niveau ultérieures se font avec sudo restic self-update. Cette commande fonctionne avec les binaires officiels, mais pas avec une copie installée depuis apt.

Sur le VPS de sauvegarde, créez un compte qui ne possède aucun autre fichier, puis copiez la clé publique de l’hôte source dans /home/resticsrv/.ssh/authorized_keys.

sudo adduser --disabled-password --gecos '' resticsrv
sudo install -d -m 700 -o resticsrv -g resticsrv /srv/restic

Initialisez le dépôt depuis la source, via SFTP.

sudo sh -c 'umask 077; head -c 32 /dev/urandom | base64 > /root/.restic-password'
export RESTIC_REPOSITORY='sftp:resticsrv@backup.example.net:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init
restic backup /etc /srv /var/backups --exclude-caches

Stockez ce mot de passe ailleurs que sur ce serveur et sur la cible de sauvegarde. Si vous le perdez, le dépôt devient illisible et il n’existe absolument aucun moyen de le récupérer. C’est la contrepartie du chiffrement côté client.

La rétention se configure avec une seule commande. Sa seconde moitié est celle qui libère l’espace disque.

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=10%

forget supprime les snapshots. prune supprime les fichiers pack référencés uniquement par ces snapshots, et --prune exécute automatiquement cette opération lorsqu’un élément a effectivement été supprimé. Sans cette option, le dépôt ne réduit jamais sa taille. restic check vérifie la structure du dépôt, et --read-data-subset=10% relit et recalcule le hash d’un dixième des fichiers pack. Cela détecte une corruption sur la cible sans imposer le coût de tout relire. L’autre forme, --read-data-subset=1/10, vérifie toujours le même dixième. En incrémentant le premier nombre chaque semaine, vous couvrez donc tout le dépôt en dix semaines.

Si une exécution est interrompue, la suivante s’arrête avec repository is already locked exclusively by PID. Vérifiez qu’aucune sauvegarde n’est en cours, puis supprimez ce fichier avec restic unlock.

Pour le stockage objet, la chaîne du dépôt devient s3:https://s3.example.net/web1, avec les identifiants dans AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY. Tout le reste est identique. C’est ainsi que restic communique avec un object store MinIO auto-hébergé exécuté sur le même VPS.

Forme 3 : rsync via SSH avec une clé limitée à la lecture

La propriété de sécurité de cette forme est la direction de la connexion. Le VPS de sauvegarde se connecte à la source et lit les données. La source ne possède aucune clé et n’a aucune route vers l’hôte de sauvegarde. La compromission de la source ne permet donc pas d’atteindre les sauvegardes.

Générez une paire de clés sur le VPS de sauvegarde, puis installez la clé publique sur la source avec une commande forcée.

command="rrsync -ro /srv",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA offsite-pull

rrsync est fourni avec le paquet rsync dans /usr/bin/rrsync sur Debian 13 et Ubuntu 24.04. -ro autorise uniquement la lecture et implique -no-del. Cette clé ne peut donc pas écrire sur la source ni y supprimer quoi que ce soit. restrict désactive les fonctions SSH inutiles ici, notamment la redirection de port et le pty. La clé ne peut donc pas servir à ouvrir une session interactive. Les chemins sont ensuite relatifs au répertoire indiqué. Le chemin distant / désigne donc /srv sur la source.

La copie conserve l’historique avec des hardlinks. Les fichiers inchangés de la nouvelle arborescence sont des hardlinks vers l’arborescence précédente. Ils occupent donc une entrée de répertoire au lieu d’une seconde copie.

DEST=/srv/mirror/web1
TODAY=$(date +%F)
LAST=$(ls -1d "$DEST"/2* 2>/dev/null | tail -1)
LINK=""
if [ -n "$LAST" ]; then LINK="--link-dest=$LAST"; fi
rsync -aH --numeric-ids $LINK -e 'ssh -i /root/.ssh/pull_ed25519' \
  pull@web1.example.net:/ "$DEST/.$TODAY.partial/"
mv "$DEST/.$TODAY.partial" "$DEST/$TODAY"

Le renommage final rend un répertoire daté fiable. Le nom n’apparaît qu’après la fin de rsync avec le code 0. Un transfert interrompu ne peut donc pas être pris pour un snapshot terminé. Supprimez les anciennes arborescences avec une seule ligne, en conservant trente snapshots.

ls -1d /srv/mirror/web1/2* | sort | head -n -30 | xargs -r rm -rf

Il faut aussi connaître le coût de cette forme. Les hardlinks dédupliquent uniquement des fichiers entiers. La modification d’un seul octet dans une image disque de 4 GB entraîne donc la copie des 4 GB entiers. Restic et PBS ne stockeraient que quelques chunks modifiés. La cible contient également vos fichiers en clair. Toute personne disposant de root sur le VPS de sauvegarde peut donc les lire.

Chiffrement côté client : la cible ne voit jamais les données en clair

Considérez le VPS de sauvegarde comme une machine que vous ne contrôlez pas entièrement. Il est géré par un fournisseur, qui emploie du personnel et dont des disques défaillants peuvent sortir du bâtiment.

restic chiffre chaque bloc sur la source avant de l’envoyer. Le dépôt contient donc du texte chiffré ainsi que des métadonnées sur les tailles et les horaires. Avec PBS, le chiffrement est activé explicitement : créez une clé, puis fournissez-la à chaque sauvegarde.

proxmox-backup-client key create /root/pbs-encryption.key
proxmox-backup-client backup root.pxar:/ --keyfile /root/pbs-encryption.key
proxmox-backup-client key paperkey --output-format text > qrkey.txt

Imprimez la clé sur papier et conservez-la dans un lieu physique sûr. La documentation Proxmox est claire sur les conséquences : sans cette clé, les fichiers sauvegardés sont inaccessibles. Conservez la clé ailleurs que sur la cible de sauvegarde, car une clé stockée à côté du texte chiffré ne protège personne.

Les miroirs rsync n’offrent pas d’équivalent. Les fichiers sont stockés comme des fichiers. Si les données sont sensibles, acceptez que la cible puisse les lire ou utilisez l’une des deux autres architectures.

Empêcher une source compromise d’effacer ses propres sauvegardes

Un attaquant qui prend le contrôle de la source cherche ensuite les sauvegardes. L’identifiant qui les envoie se trouve justement sur cette machine. S’il permet également de les supprimer, l’attaquant l’utilisera.

PBS répond à ce problème avec des rôles. Un token qui possède uniquement DatastoreBackup peut écrire de nouveaux snapshots et restaurer les siens. Il ne peut pas effectuer le pruning, car la suppression d’un snapshot nécessite le privilège distinct Datastore.Prune. Exécutez la rétention côté PBS : la source ne détient alors jamais d’identifiant permettant de supprimer quoi que ce soit.

restic over SFTP ne permet pas cette séparation, car la clé SSH qui écrit dans le repository peut également y supprimer des données. La solution consiste à utiliser le backend REST. Exécutez rest-server sur le backup VPS avec --append-only. Cette option autorise la création de nouvelles sauvegardes, mais empêche la suppression et la modification des sauvegardes existantes. Configurez ensuite le client pour utiliser rest:https://backup.example.net:8000/web1 avec RESTIC_REST_USERNAME et RESTIC_REST_PASSWORD. Un restic forget --prune lancé depuis la source échoue alors, ce qui est le résultat recherché. La rétention doit donc être exécutée depuis une seconde machine avec son propre identifiant. Le manuel de restic recommande également --keep-within plutôt que des politiques basées sur un nombre de snapshots pour les repositories append-only. Sinon, un attaquant qui remplit le repository avec des snapshots inutiles pourrait faire sortir vos véritables sauvegardes d’une fenêtre --keep-last.

rsync résout le même problème de manière structurelle en effectuant un pull, car la source ne détient aucun identifiant permettant d’accéder à la cible.

Une règle couvre ces trois architectures : l’identifiant qui permet de supprimer les sauvegardes doit se trouver sur une machine différente de celle qui est sauvegardée.

Planifiez un exercice de restauration

Une sauvegarde que vous n’avez jamais restaurée reste une hypothèse. Réservez une heure chaque trimestre et testez-la.

restic snapshots
restic restore latest --target /var/tmp/restore-test --include /etc/nginx
diff -r /etc/nginx /var/tmp/restore-test/etc/nginx

diff -r sans rien afficher signifie que l’arborescence restaurée correspond à l’arborescence en production. Avec PBS, le même exercice utilise proxmox-backup-client restore host/web1/2026-08-13T02:30:00Z root.pxar /var/tmp/restore-test/, ainsi qu’une tâche de vérification planifiée qui relit les chunks sur la cible et signale les erreurs de checksum.

L’exercice doit prouver davantage que l’intégrité des octets.

• Restaurez depuis une troisième machine, et non depuis la source, car la source est précisément ce que vous supposez avoir perdu. Le mot de passe du repository ou la clé PBS doit donc être accessible sans cette machine.
• Chronométrez la restauration et notez la durée, puis comparez-la au RTO annoncé. Le graphique ci-dessus indique le débit minimal de transfert. La durée réelle inclut aussi le déchiffrement et l’écriture sur disque, ainsi que le temps nécessaire pour déterminer quel snapshot vous vouliez restaurer.
• Restaurez un élément avec un état, par exemple un dump de base de données que vous chargez ensuite dans une instance de test. Un fichier tar qui s’extrait correctement ne prouve pas que l’application démarre.

Le disque le moins cher du monde ne vaut rien tant que vous n’avez pas effectué au moins une restauration depuis celui-ci.

FAQ

Un instantané chez mon fournisseur VPS constitue-t-il une sauvegarde hors site ?

Non. Un instantané du fournisseur se trouve dans le même compte, derrière le même accès au panneau de contrôle et sur la même facture que le serveur copié. Toute personne qui obtient ces identifiants peut supprimer le serveur et tous ses instantanés au cours de la même session. Les instantanés sont utiles pour effectuer rapidement un rollback avant une mise à niveau risquée, mais ils ne constituent pas un second emplacement. Une copie hors site se trouve dans un autre compte, idéalement chez un autre fournisseur, avec des identifiants que la machine source ne détient pas.

De quel espace disque ai-je besoin pour conserver un mois de sauvegardes ?

Dimensionnez-le selon l’ancienneté de votre instantané le plus ancien, et non selon le nombre d’instantanés. Un outil avec déduplication ne stocke chaque bloc unique qu’une seule fois. Le dépôt correspond donc approximativement à la taille de la source, à laquelle s’ajoutent les nouvelles données uniques produites chaque jour, multipliées par le nombre de jours de conservation. Pour 500 GB de données qui changent de 5 GB par jour, une semaine de sauvegardes quotidiennes occupe environ 535 GB et une année complète d’historique occupe 2,325 GB. Prévoyez une marge supplémentaire, car un disque plein fait échouer la sauvegarde suivante. De plus, prune de restic a besoin d’espace libre pour réorganiser les fichiers pack avant de pouvoir le libérer.

Un serveur compromis peut-il supprimer ses propres sauvegardes hors site ?

Oui, sauf si vous avez conçu l’architecture pour l’empêcher. Avec un dépôt SSH ou SFTP classique, la clé qui permet d’écrire peut aussi supprimer des données. Donnez à la source un identifiant qui ne peut pas supprimer de données : un jeton d’API PBS possédant uniquement le rôle DatastoreBackup, qui ne dispose pas du privilège Datastore.Prune, ou restic associé à rest-server démarré avec --append-only, qui refuse la suppression et la modification des sauvegardes existantes. Une architecture pull va plus loin, car la source ne détient alors aucun identifiant pour l’hôte de sauvegarde. Exécutez la rétention depuis le côté qui n’est pas la source.

Dois-je exécuter Proxmox Backup Server ou restic sur le VPS de sauvegarde ?

Choisissez l’outil selon l’unité que vous devez restaurer. Si la source est Proxmox VE et que vous voulez récupérer une machine virtuelle complète, utilisez PBS, car il sauvegarde au niveau de l’image disque et restaure une VM en une seule étape. Si la source est un hôte Linux et que vous voulez récupérer des fichiers et des dumps de base de données, utilisez restic. Il nécessite uniquement un compte SSH sur la cible et chiffre les données avant leur envoi. Il est courant d’exécuter les deux : PBS pour l’hyperviseur et restic pour les serveurs qui ne sont pas hébergés dessus.

Combien de temps faut-il pour restaurer une sauvegarde depuis un VPS ?

Divisez la taille des données par le débit de la liaison pour obtenir une durée minimale, puis ajoutez le temps nécessaire au déchiffrement et à l’écriture. 500 GB sur une liaison à 100 Mbit/s représentent 11.1 heures au débit maximal de la liaison. La même restauration sur un port à 1 Gbit/s représente 1.1 heures. De nombreux petits fichiers ralentissent l’opération par rapport à ce calcul en raison du coût associé à chaque fichier. Chronométrez une restauration réelle et utilisez cette mesure, car c’est la seule valeur sur laquelle votre plan de reprise peut compter.