Les sauvegardes cloud sont lentes via le VPN : trouvez la vraie phase

Une sauvegarde qui rampe à travers un VPN invite à l'expérience évidente : déconnecter le tunnel et mesurer à nouveau. Cette expérience répond souvent à une autre question, car la tâche calculait peut-être des empreintes ou attendait une nouvelle tentative plutôt que de déplacer des octets. Séparez d'abord les phases, et la plainte devient un test précis avec un résultat attendu précis. La route ne devient candidate que lorsque la phase de transfert est celle qui est réellement lente.

Dans quelle phase se trouve la tâche quand elle semble lente

Les outils de sauvegarde passent par des phases : découvrir les fichiers, les lire et calculer leurs empreintes, compresser, chiffrer, téléverser, puis vérifier. Chaque phase a son propre goulot d'étranglement, et seules certaines touchent le réseau. Un outil qui n'annonce encore aucune phase vous dit qu'il n'a pas fini d'analyser.

Une tâche qui passe vingt minutes à préparer un million de petits fichiers ne s'accélérera pas quand le tunnel ira plus vite. Une tâche qui sature le lien montant est un problème de capacité avec une autre solution. Lisez la sortie de progression pendant le délai, notez la phase et relevez l'horodatage, car la phase au moment de la plainte est la seule qui compte. Les petits fichiers se comportent aussi différemment d'un gros objet, car les allers-retours par fichier dominent et le transfert n'atteint jamais un débit stable. Comparez ce qui est comparable avant de conclure quoi que ce soit sur le tunnel.

Un point de terminaison public et un NAS privé échouent différemment

Un service de sauvegarde public possède sa propre connexion applicative authentifiée, et le tunnel n'est qu'un saut sur un chemin plus long. Un NAS privé dépend généralement de ce tunnel pour l'accessibilité de base à votre réseau. Cette différence décide si déconnecter constitue une référence valable ou un test de rien.

Dans le cas public, la même tâche par une autre route peut être une comparaison honnête quand la politique l'autorise. Dans le cas privé, retirer le tunnel ne laisse aucune route vers le serveur, donc le résultat décrit le chemin que vous avez supprimé et non celui que vous utilisez.

Un blocage est une défaillance différente d'un transfert lent

La troisième colonne de ce tableau décide si un test de stabilité peut seulement être exécuté, car une référence qui supprime le tunnel n'a de sens que là où un autre chemin existe. Avec une référence utilisable, regardez la forme de la défaillance plutôt que son débit moyen. Un envoi faible mais régulier indique la capacité, tandis qu'une tâche qui bloque et redémarre indique une interruption, une authentification ou un fichier problématique. Ces deux cas produisent des plaintes presque identiques et des réparations totalement différentes.

Les nouvelles tentatives faussent toute mesure, car les octets sur le câble peuvent être plus nombreux que la quantité qui a réellement changé. Lisez le comportement de reprise avant d'interrompre à nouveau la tâche pour voir ce qui se passe, car les envois fragmentés et reprenables se rétablissent à peu de frais, contrairement au redémarrage d'un fichier entier. Un tunnel qui se reconnecte toutes les quelques minutes ressemble aussi à un problème de bande passante alors qu'il s'agit en fait d'un problème de stabilité. Le MTU du chemin aggrave cela, car un tunnel qui réduit la charge utile bloque les grands segments tandis que les petits passent.

journalctl -u wg-quick@wg0 -n 50 --no-pager
ss -tin dst :443
ping -M do -s 1400 -c 3 backup.example.com

Un seul envoi peut affamer tous les autres flux

Un envoi qui remplit le lien montant rend les appels et la navigation non réactifs, et la sauvegarde est rarement la seule chose à se disputer ce lien. Un second client de synchronisation produit le même symptôme à lui seul. Avant d'accuser le tunnel, regardez ce qui d'autre envoie.

Utilisez la planification ou le plafond de bande passante que l'outil documente au lieu de vous battre pour le débit maximal ; laisser de la marge pour le travail interactif vaut généralement mieux que les derniers pourcents. Vérifiez ensuite à quoi le plafond s'applique réellement, car certains outils limitent par fichier, d'autres toute l'exécution, et d'autres ignorent complètement le coût des petits fichiers. Un plafond qui ne correspond pas à la charge de travail ne change rien. Le tunneling divisé mérite aussi la méfiance ici, car exclure le lanceur du tunnel n'exclut pas le service auxiliaire qui effectue l'envoi. Rclone, par exemple, publie à la fois les limites de transfert et le comportement de nouvelle tentative dans sa documentation, ce qui en fait une référence utile sur ce qu'un plafond devrait contrôler.

Terminez par une restauration, pas par un test de vitesse

Un envoi terminé n'est pas une sauvegarde tant que rien n'en est restauré. Confirmez que la version attendue existe, puis restaurez un fichier représentatif avec la procédure documentée par l'outil. Conservez les informations de récupération ailleurs que sur la machine ou le profil que vous pourriez perdre, et ne jetez jamais une sauvegarde qui fonctionne juste pour garder une expérience bien rangée.

restic snapshots --latest 3
restic restore latest --target /tmp/restore-check --include /etc/hosts

Répétez le transfert et la restauration après le changement de réseau, afin que l'amélioration serve démontrablement la sauvegarde et pas seulement un déplacement plus rapide des données. C'est cette seconde exécution qui clôt le ticket. Un transfert plus rapide avec une restauration non testée est une façon plus lente de rester sans protection.