Architecture réseau pour fenêtres de sauvegarde : mise en œuvre pratique de l’optimisation WAN, du QoS et du throttling

Une architecture réseau robuste pour les fenêtres de sauvegarde rend les sauvegardes prévisibles : RPO/RTO RESTent atteignables, le trafic de production RESTe protégé et la capacité de RESTauration est assurée. Ce guide s’adresse aux administrateurs, ingénieurs systèmes et opérateurs et explique de manière pratique quelles mesures comptent, où positionner utilement la QoS et le throttling, comment fonctionne l’optimisation WAN et quels pièges spécifiques à MySQL il faut prendre en compte.

Pourquoi les sauvegardes sollicitent les ressources réseau

Le trafic de sauvegarde est à fort volume et souvent hautement parallèle. Contrairement aux applications interactives, le transfert de sauvegarde n’est typiquement pas sensible à la latence, mais il est en revanche sensible à la perte de paquets et à la variation de la RTT (Round Trip Time = temps aller‑retour d’un paquet). TCP réduit sa taille de fenêtre en cas de perte de paquets ; il en résulte souvent une perte de débit drastique, même si la bande passante nominale est disponible. De plus, les goulots d’étranglement ne sont souvent pas la capacité de la liaison elle‑même, mais la mise en file d’attente sur des pare‑feu, des passerelles VPN ou les bords des fournisseurs.

Architecture réseau pour les fenêtres de sauvegarde : décisions de conception pratiques

Planifiez les sauvegardes comme un service avec des caractéristiques proches d’un SLA : fenêtres temporelles, bande passante minimale garantie, utilisation maximale et priorité claire par rapport au trafic de production. L’essentiel est la mesurabilité, des points de contrôle directement au niveau du goulot d’étranglement et une stratégie de repli documentée.

Vision cible : les fenêtres de sauvegarde comme service réseau planifiable

Considérez les sauvegardes comme un service distinct avec des règles claires :

• Fenêtres temporelles définies et budgets réseau par site/proxy.
• Priorisation : le trafic de production a la priorité ; les sauvegardes utilisent la capacité réservée.
• Mesurabilité : RTT, perte, drops de file d’attente et débit des jobs visibles de façon corrélée.
• Stratégie de repli claire en cas de mauvaise configuration.

Baseline et analyse des goulots : mesurer avant de concevoir

Mesurez d’abord, puis définissez des politiques. Les métriques importantes sont le goodput (débit utile), la RTT, la perte de paquets, le jitter, les drops dans les files d’attente des équipements de bord et le nombre de flux TCP parallèles. Sans cette baseline, les règles de QoS ou de throttling risquent d’être appliquées à l’aveugle et de déplacer les problèmes plutôt que de les résoudre.

Vérifications rapides (Linux/Windows)

Des contrôles rapides aident à détecter promptement des problèmes d’MTU ou de retransmissions.

# Interface-Statistiken
ip -s link

# TCP-Statistiken
ss -s

# Pfad-Latenz und Loss
ping -c 50 -i 0.2 <ziel-ip>

# Path-MTU testen (IPv4: 1472 + 28 Header = 1500)
ping -M do -s 1472 -c 3 <ziel-ip>

# Pfad-Analyse
tracepath <ziel-ip>

# Windows Adapter-Statistiken
Get-NetAdapterStatistics

# TCP-Verbindungsstatus
Get-NetTCPConnection | Group-Object -Property State | Sort-Object Count -Descending

Principes de topologie : où intervenir

Principe A : séparation logique du chemin de données de sauvegarde

Des VLAN/VRF dédiés (VRF = instance de routage isolée), des adresses IP dédiées et des ACL claires permettent une classification fiable. Cela évite que le trafic de production soit classé par erreur comme sauvegarde.

Principe B : contrôler les goulots d’étranglement à leur source

Le shaping et le queueing doivent être placés aussi près que possible de l’egress WAN (sortie vers le fournisseur). Ne limitez pas seulement dans le LAN si la passerelle VPN ou le bord du fournisseur forment des files d’attente ; sinon des pertes incontrôlées hors de votre contrôle apparaîtront.

Principe C : déployer des proxies de sauvegarde

Les proxies de regroupement réduisent les flux WAN, permettent la déduplication/la compression avant le transfert et simplifient le throttling. Les inconvénients sont une charge CPU supplémentaire due à la compression/chiffrement et un point de défaillance supplémentaire qui doit être pris en compte dans les runbooks et la supervision.

Optimisation WAN : quand elle est utile et quand elle ne l’est pas

L’optimisation WAN (déduplication, compression, byte-caching) n’est efficace que si elle intervient avant le chiffrement et si les données contiennent des motifs répétitifs. Les contenus médias, les sauvegardes fortement modifiées ou les archives déjà compressées offrent peu de réduction. Dans des scénarios Zero‑Trust, où les données sont systématiquement chiffrées, le bénéfice disparaît souvent.

Déduplication et compression : l’ordre compte

La déduplication ne peut détecter que des séquences d’octets identiques ou très similaires. La compression peut réduire le volume de données, mais si le chiffrement intervient en amont (p. ex. TLS/SSH), les deux sont inefficaces. Si votre workflow de sauvegarde autorise la compression, effectuez-la avant le chiffrement — ou travaillez avec un proxy de sauvegarde qui déduplique en clair puis chiffre ensuite.

Optimisations TCP : réalité vs théorie

Sur des liaisons à RTT élevé, les flux TCP nécessitent des fenêtres plus grandes (TCP Window Scaling). Le tuning du noyau est souvent secondaire par rapport à un chemin stable, une MTU/MSS correcte et une perte de paquets évitable. Dans des environnements VPN ou SD‑WAN, le MSS‑clamping est souvent le moyen le plus efficace contre la fragmentation et les erreurs PMTUD.

QoS pour les sauvegardes : classifier, marquer, mettre en file

La QoS protège le trafic métier en situation de contention. Les prérequis sont une classification fiable, des frontières de confiance claires et des mécanismes de mise en file appropriés.

1) Identifier clairement le trafic

Utilisez des IP sources, IP de destination ou des ports dédiés plutôt que des identifications d’applications peu fiables. Une IP dédiée pour les serveurs de sauvegarde est la méthode la plus simple et la plus robuste pour garantir la classification.

2) Marquage DSCP et frontière de confiance

Marquez le trafic de préférence au niveau du backup‑proxy ou à l’endroit de sa génération. Sur l’Internet public, le DSCP est rarement fiable de bout en bout ; en revanche, au sein de votre réseau il est très efficace si tous les équipements respectent le marquage.

# Beispiel: DSCP setzen mit iptables (mangle table)
iptables -t mangle -A POSTROUTING -s 10.0.10.0/24 -o eth0 -j DSCP --set-dscp 8

3) Mise en file et AQM

Utilisez l’Active Queue Management (AQM) comme FQ‑CoDel ou CAKE pour éviter le bufferbloat. Placez les sauvegardes dans une file de priorité basse, mais avec un minimum défini (bande passante garantie), afin que les travaux longs ne soient pas complètement étouffés.

Throttling : pratique et fiable

Le throttling limite le débit de manière ciblée. Il peut être appliqué dans l’outil de sauvegarde, sur l’hôte ou à la périphérie du réseau. Le shaping en périphérie protège indépendamment de l’outil ; les limites côté outil sont plus proches de l’application et plus faciles à coordonner. Les combinaisons fonctionnent le mieux.

Exemple : shaping côté hôte avec tc (Linux)

Cet exemple limite le trafic sortant à 200 Mbit/s. Adaptez le nom de l’interface et les valeurs, et documentez les modifications dans le processus de changement.

IFACE="eth0"
RATE="200mbit"

# Bestehende qdisc anzeigen
tc qdisc show dev "$IFACE"

# Root-qdisc setzen (TBF = Token Bucket Filter)
sudo tc qdisc replace dev "$IFACE" root tbf rate $RATE burst 512kbit latency 50ms

# Prüfen
tc -s qdisc show dev "$IFACE"

Attention : si le goulot d’étranglement se situe en amont de l’hôte (p. ex. VPN), la limitation côté hôte est insuffisante. Un simple rate-limiting sans AQM peut entraîner des congestions incontrôlées.

Marquage fondé sur des filtres et classes TC

Approche typique : marquer avec iptables/nftables et filtrer dans tc par fwmark.

# Markieren im mangle table
iptables -t mangle -A OUTPUT -s 10.0.0.20 -j MARK --set-mark 10

# tc: Klasse und Filter
tc qdisc add dev eth0 root handle 1: htb default 30
tc class add dev eth0 parent 1: classid 1:10 htb rate 200mbit ceil 200mbit
tc filter add dev eth0 protocol ip parent 1: prio 1 handle 10 fw flowid 1:10

MySQL-Backups: Netzwerk- und Datenpfad-Fallen

Les sauvegardes MySQL varient fortement selon la méthode : les dumps logiques (mysqldump) sollicitent le CPU et les E/S et génèrent beaucoup de petites écritures ; les sauvegardes physiques (Percona XtraBackup / innobackupex) sont séquentielles et en blocs ; le binlog-shipping produit des flux continus. Côté réseau, les problèmes typiques sont :

• Une trop grande parallélité de plusieurs jobs de sauvegarde entraîne une utilisation inéquitable des files d’attente.
• Compression/chiffrement au mauvais endroit empêchant la déduplication.
• Le repository-IO ou l’indexation d’ingest limite le débit global.

La supervision doit mesurer séparément l’export, le transfert réseau et l’ingestion cible. Ce n’est qu’ainsi que vous identifierez si un job lent est limité par le réseau, le CPU/IO de l’émetteur ou par le repository.

Praktische Streaming-Beispiele (Throttling möglich)

Des exemples montrent comment combiner des sauvegardes MySQL avec une limitation réseau. À noter : pv limite le débit par flux, rsync dispose de –bwlimit, et ssh/openssl peuvent être liés au CPU.

# mysqldump -> gzip -> pv (20 MB/s) -> ssh -> Zieldatei
mysqldump -u backup -p --single-transaction --quick --databases prod_db 
  | gzip -c | pv -L 20m | ssh backup@repo 'cat > /backups/prod_db.sql.gz'

# Physisches Percona XtraBackup streamen mit Limit (200 Mbit/s)
innobackupex --stream=xbstream /var/lib/mysql 
  | pv -L 25m | ssh backup@repo 'cat > /backups/site1.xbstream'

# rsync mit Bandbreitenlimit
rsync -av --progress --bwlimit=20000 /data/backups/ backup@repo:/backups/site1/

Remarque : si vous devez chiffrer, procédez ainsi : compresser > chiffrer > transporter. La déduplication/optimisation WAN ne fonctionne que avant le chiffrement.

MySQL-spezifische Checks vor und nach dem Backup

Vérifications importantes

• Cohérence du schéma et transactions actives : pour les dumps logiques, utilisez –single-transaction.
• Conservation de la position du binlog : important pour la récupération Point-in-Time.
• I/O du repository : mesurer les IOPS et la latence pendant l’ingestion.

Messung und Monitoring: Was in Dashboards gehört

Construisez des tableaux de bord qui regroupent les métriques d’export, de transfert réseau et d’ingest. Les éléments à inclure :

• Goodput vs. utilisation de l’interface
• Longueurs de file et pertes (drops) à l’edge WAN et sur les VPN
• Compteurs DSCP et taux d’erreur de classification
• Durée des jobs de sauvegarde, octets envoyés, taux d’erreur
• IOPS du repository et latence d’écriture

Une vue combinée montre si la QoS masque des problèmes réseau ou fournit de réelles améliorations.

Troubleshooting: Häufige Fehlerbilder und Prüfungen

Fehlerbild: Backups langsam, Business stabil

Généralement, la file de sauvegarde est trop RESTrictive ou le repository cible est limité. Vérifiez les queue-counters, les logs de jobs et les IOPS du stockage. Augmentez les limites par étapes, vérifiez la parallélisation et ajustez les fenêtres temporelles.

Fehlerbild: Business bleibt zäh trotz QoS

Alors la QoS n’agit pas sur le vrai goulot d’étranglement ou la classification est erronée. Vérifiez le RTT/les pertes sur chaque saut, les statistiques VPN et si les DSCP sont effectivement appliqués. Une correction fréquente consiste à effectuer le shaping plus près de l’egress WAN ou à utiliser des tunnels séparés pour les applications métier critiques.

Symptômes : problèmes spécifiques au site

Les causes sont souvent des particularités du fournisseur, la MTU, les paramètres d’offload ou un routage asymétrique. Vérifiez MTU/MSS, les statistiques des tunnels et le chemin aller/retour. Le MSS‑Clamping et des politiques cohérentes aident fréquemment.

Tests réseau rapides pour isoler la cause

Quelques vérifications utiles qui fournissent rapidement des indications :

# Durchsatztest (iperf3) mit 8 parallelen Streams und JSON-Ausgabe
iperf3 -c  -P 8 -J

# TCP-Retransmissions mit tshark filtern
tshark -i eth0 -Y "tcp.analysis.retransmission" -w retransmissions.pcap

# Capture komplette Backup-Session (vorsichtig bei großen Dateien)
tcpdump -i eth0 host  and port 22 -w backup-session.pcap

Rollback und Notfall-Drosselung

Des possibilités de repli rapides sont indispensables. Maintenez des commandes simples et testées dans le runbook pour supprimer ou réduire le QoS/Throttling.

# QoS/TC komplett entfernen
sudo tc qdisc del dev eth0 root

# Temporäres Host-Limit setzen (falls Edge-Config fehlschlägt)
sudo tc qdisc replace dev eth0 root tbf rate 100mbit burst 512kbit latency 50ms

Documentez les responsables, les canaux de communication et les étapes de test orientées résultat pour le rollback.

Change-Management und Teststrategie

Les modifications de QoS ou de throttling doivent être effectuées dans des fenêtres de changement avec des tests canary. Procédure :

1. Sandbox : test sur un site ou un petit groupe d’hôtes.
2. Mesure : comparer les métriques avant/après (Goodput, RTT, pertes).
3. Déploiement progressif avec critères d’acceptation documentés.

Operational-Checkliste

• Identité du trafic : sources/cibles de sauvegarde définies de façon univoque.
• Goulot d’étranglement : où se situe le bottleneck (WAN‑Edge, VPN, fournisseur, référentiel) ?
• MTU/MSS : overhead du tunnel pris en compte, PMTUD vérifié ou MSS‑Clamping appliqué.
• Politique QoS : classification, priorités et compteurs sont documentés.
• Throttling : limites par outil par site/proxy définies.
• Parallélisme : nombre de streams adapté à la capacité du lien.
• Monitoring : RTT/pertes/drops + métriques de job + I/O du repository visibles.
• Rollback : étapes documentées, court délai de retour, responsable clairement identifié.

Conclusion

Des fenêtres de sauvegarde stables résultent de trois décisions imbriquées : un budget clair de bande passante (throttling/shaping), une priorisation propre (QoS au vrai goulot d’étranglement avec classification univoque) et une optimisation WAN ciblée uniquement là où elle réduit mesurablement les octets ou les retransmissions. Complété par le contrôle MTU/MSS, un parallélisme adapté et une surveillance distincte pour l’export, le réseau et l’ingestion cible, cela rend la fenêtre de sauvegarde planifiable sans mettre en danger l’exploitation. Testez les changements de façon canary, maintenez des rollbacks simples et mesurez toujours dans au moins trois domaines : export, réseau, repository.

FAQ

Voir la FAQ à la fin de cet article pour des réponses rapides aux questions typiques sur le QoS, le throttling et les sauvegardes MySQL.

Risques d’architecture, d’intégration et d’exploitation souvent négligés

Lors de la mise en œuvre des fenêtres de sauvegarde, la bande passante et la QoS ne sont pas les seuls éléments décisifs : des détails d’intégration et d’exploitation peuvent s’avérer fatals par la suite. Faites attention à la manière dont le chiffrement, les offloads matériel et les appliances WAN spécialisées interagissent : de nombreux optimiseurs Dedupe/WAN ne fonctionnent que sur un flux de données non chiffré ou s’ils peuvent assurer la terminaison TLS. Décidez délibérément si le chiffrement doit être effectué côté client, côté backup‑proxy ou pendant le transport — chaque option a des conséquences sur la déduplication, le key‑management et la capacité de RESTauration.

Des fonctions matérielles comme SR‑IOV, DPDK ou NIC‑Checksum/GSO/GRO peuvent fausser les métriques de mesure et contourner le traffic‑shaping. Testez donc dans une topologie de staging avec exactement les mêmes réglages d’offload qu’en production. Ne vous fiez pas uniquement aux compteurs Netflow échantillonnés : des captures complètes de paquets et des traces basées sur eBPF aident à rendre visibles les retransmissions réelles et le bufferbloat.

Contrôle rapide pour l’exploitation :

• Valider : déduplication/compression avant ou après chiffrement ? Documenter.
• Key‑Management : sécuriser les clés, planifier rotation et tests de RESTauration.
• Offloads : test avec/sans NIC‑Offload ; mesurer la charge CPU (AES‑NI) et le goodput.
• Observability : pcap/iperf + traces eBPF pour des sessions de sauvegarde réelles.
• Runbook : documenter la désactivation rapide des optimiseurs et les throttles d’urgence.

Ces perspectives réduisent les surprises et rendent les fenêtres de sauvegarde résilientes face aux incompatibilités entre réseau, stockage et composants logiciels d’entreprise spécifiques.

Pour ce sujet, le backup throttling et le traffic shaping sont également importants. L’article situe ces aspects de manière compréhensible et montre ce qui compte au quotidien.