Proxmox Backup Server vs Veeam pour VMware : lequel est meilleur pour des restaurations rapides et des opérations simples

La décision en 60 secondes

Si votre environnement est très centré sur VMware et que vous avez besoin de workflows éprouvés « remettez-moi en marche maintenant » (Instant Recovery, restaurations granulaires, éléments applicatifs, large écosystème, options bande/cloud, beaucoup de garde-fous), Veeam est généralement le choix le plus sûr. Ce n’est pas toujours élégant. Mais il est éprouvé dans les modes de défaillance exacts que rencontrent la plupart des environnements VMware.

Si vous voulez une plomberie de sauvegarde simple, rapide et native Linux avec une excellente déduplication et des performances de restauration prévisibles et que vous êtes à l’aise pour construire vous-même une partie des intégrations, PBS peut être un dépôt + moteur de sauvegarde très performant. Il brille quand vous le considérez comme du stockage : de bons disques, ZFS réglé raisonnablement, et un chemin réseau qui n’est pas une réflexion après coup.

La partie opinionnée : ne choisissez pas sur la base de ratios théoriques de déduplication. Choisissez en fonction de votre workflow de restauration, de la maturité opérationnelle de votre équipe et de ce qui se passe quand l’unique administrateur sauvegarde est dans un avion.

Blague n°1 : Les sauvegardes, c’est comme les parachutes : en avoir un, c’est super; découvrir qu’il est mal plié, c’est un moment exceptionnellement mauvais.

Faits et contexte à utiliser en réunion

• Les snapshots VMware ont changé la conception des sauvegardes. Les outils modernes d’image disque pour VMware dépendent des snapshots de VM pour obtenir une vue cohérente à un instant donné, puis déplacent les données ailleurs.
• Changed Block Tracking (CBT) a été un tournant. Le CBT a rendu les incrémentales rapides en suivant les régions de disque modifiées. Il a aussi créé une classe d’« incrémentales silencieusement mauvaises » lorsque le CBT est invalidé ou bogué — d’où le besoin de full périodiques ou de vérifications synthétiques.
• La déduplication est passée de « agréable » à « obligatoire » avec l’explosion des VM. Mais elle a déplacé le goulot d’étranglement de la capacité disque vers le CPU, la RAM et les schémas d’E/S aléatoires.
• ZFS a popularisé le stockage axé intégrité pour le matériel grand public. Les sommes de contrôle et la correction par scrub ont changé les attentes : le stockage ne doit pas corroder silencieusement vos sauvegardes.
• L’immuabilité est devenue courante car les rançongiciels ciblent désormais les sauvegardes. Quand les attaquants ont appris à supprimer les dépôts et les catalogues, « air gap » et immuabilité ont cessé d’être des mots à la mode.
• L’architecture proxy/repository de Veeam provient des contraintes de l’ère Windows. Elle est modulaire parce qu’elle devait l’être : modes de transport différents, stockage différent, réseaux différents, nombreux schémas de déploiement.
• PBS a été conçu dès le départ avec des chunks adressés par contenu. Il stocke des chunks dédupliqués avec des sommes de contrôle fortes et expose un modèle simple : datastores, namespaces, verify, prune.
• Les fonctions « Instant recovery » sont plus anciennes qu’on ne le pense. Monter une sauvegarde comme une VM en cours d’exécution est essentiellement de la virtualisation de stockage — concept mature, mise en œuvre difficile.
• Les dépôts Linux sont devenus une bonne pratique Veeam au fil du temps, surtout parce que XFS/Reflink et les schémas de dépôt durcis correspondent mieux aux modèles de menace modernes qu’un simple partage Windows.

Ce que signifie réellement « restauration rapide » (et ce qui la ralentit)

Le temps de restauration n’est pas un nombre unique. C’est un pipeline :

1. Trouver rapidement les métadonnées : catalogue, index, chaînes de sauvegarde.
2. Lire les données de sauvegarde rapidement : débit du dépôt, E/S aléatoires, réhydratation de la déduplication, décompression.
3. Écrire en production rapidement : performances du datastore, réseau, comportement du contrôleur de stockage.
4. Rendre bootable : différences de pilotes, cohérence applicative, particularités AD/SQL/Exchange, etc.

Les tueurs cachés :

• Les petites E/S aléatoires sur le dépôt (bases de données de déduplication, magasins de chunks, recherches de métadonnées).
• CPU sous-estimé (décompression/chiffrement/réhydratation ne sont pas gratuits).
• Suroffre réseau (un 10GbE qui se comporte comme du 1GbE quand le buffer du switch souffre).
• Pathologie de chaîne de snapshots (stun lors de la suppression de snapshot, pics de latence de stockage).
• « Restaurer au même endroit cassé » (écrire dans un datastore déjà malade en latence).

Les restaurations rapides viennent d’un principe ennuyeux : faire du chemin de restauration le chemin le plus simple. Les fonctions sophistiquées ne battent pas la physique. Elles la contournent.

Architectures : comment PBS et Veeam déplacent réellement les octets

PBS en pratique

PBS est un serveur de sauvegarde dédié avec des datastores. Les sauvegardes sont découpées en chunks, compressées et dédupliquées. L’intégrité est une priorité : les chunks ont des sommes de contrôle ; vous pouvez vérifier les datastores et détecter la corruption tôt. Opérationnellement, on a l’impression d’un appareil de stockage qui parle sauvegarde.

Pour VMware, l’approche habituelle est : un processus de sauvegarde lit les données de la VM (souvent via des agents ou des outils d’intégration) et les dépose dans PBS. PBS n’est pas, à lui seul, une suite VMware « tout-en-un » où l’on clique simplement pour protéger tout ; il est excellent dans ce qu’il fait : stocker et servir les sauvegardes rapidement et de façon fiable. L’histoire d’intégration peut demander plus d’ingénierie selon votre environnement.

Veeam pour VMware en pratique

Veeam est une plate-forme : serveur de sauvegarde, proxies, repositories, scale-out repositories (SOBR), divers transports (HotAdd, NBD, Direct SAN), traitement aware applicatif, et une longue liste de modalités de restauration. Il est conçu pour se placer au milieu du chaos d’entreprise et quand même faire le boulot.

Le compromis : plus de boutons, plus de pièces mobiles, plus de choses à patcher, plus de modèles d’autorisation, plus de certificats, plus de « pourquoi ce service utilise ce port ». Vous avez la puissance, mais aussi la responsabilité.

Implication sur la vitesse de restauration :

• PBS a tendance à être prévisible si le stockage sous-jacent est sain et que vous ne le privez pas de RAM/CPU.
• Veeam a tendance à être adaptable — vous pouvez ajouter des proxies, changer de mode de transport, tierer vers différents stockages — mais il est plus facile de construire accidentellement un chemin de restauration qui est rapide sur le papier et lent en réalité.

Implication opérationnelle :

• PBS est à la manière d’un appliance. Moins de composants. Modèle mental fort.
• Veeam est à la manière d’un système. Vous avez besoin de normes : nommage, agencement des repositories, placement des proxies, gestion des identifiants et contrôle des changements.

Chemins de restauration qui comptent : VM complète, niveau fichier et moments « oups »

Restauration complète de VM (RTO prioritaire)

L’avantage de Veeam est l’étendue des workflows de restauration et le polish opérationnel autour d’eux. Instant VM Recovery (exécuter la VM depuis le dépôt de sauvegarde) peut réduire drastiquement le RTO lorsque le stockage de production est lent, mort ou politiquement inaccessible. Le risque est que « instant » devienne « instantanément lent » si le dépôt n’a pas été construit pour les schémas d’I/O des VM.

PBS peut restaurer efficacement si votre pipeline réécrit vers le stockage VMware au débit ligne et si vous n’êtes pas piégé par un thrash méta. Mais PBS ne crée pas magiquement une VM en cours d’exécution à partir d’un magasin dédupliqué sans l’orchestration orientée VMware qui l’entoure. Si vous attendez un boot instantané en un bouton pour VMware, Veeam est simplement plus susceptible de vous fournir ce que vous voulez aujourd’hui.

Restauration au niveau fichier (la demande la plus courante)

La plupart des restaurations ne sont pas des catastrophes. Ce sont des « qui a supprimé le tableau » et « ce fichier de conf de la semaine dernière ». Veeam dispose d’explorateurs matures pour les systèmes de fichiers invités et les applications dans de nombreux environnements. PBS peut prendre en charge la restauration au niveau fichier selon la manière dont vous sauvegardez (agents, niveau invité ou images montées), mais ce n’est pas un univers « Explorer » uniforme pour chaque charge de travail.

Éléments applicatifs (où le temps se noie)

Restauration d’objet AD, point-in-time SQL, récupération d’éléments de boîte aux lettres Exchange : c’est là que les vendeurs de sauvegarde d’entreprise gagnent leur vie. Veeam est fort ici car il a investi des années dans le traitement aware applicatif et des outils de récupération. PBS peut faire partie d’une stratégie, mais vous pourriez assembler des sauvegardes natives applicatives, des scripts et des validations vous-même.

Rançongiciel et restaurations « je ne fais plus confiance à l’environnement »

Les sauvegardes immuables et les dépôts durcis sont aujourd’hui indispensables. Veeam a de solides schémas pour les repositories Linux durcis et des fenêtres d’immuabilité. PBS, en étant natif Linux avec vérification par checksum et un modèle de datastore clair, se prête bien à la construction de conceptions robustes et résistantes aux altérations — surtout combiné à des accès admin restreints et des cibles de réplication hors ligne.

Blague n°2 : La seule chose plus optimiste que « nous restaurerons rapidement » est « nous testerons les restaurations le trimestre prochain ».

Opérations simples : ce que vous ferez chaque semaine

Les restaurations rapides sont surtout la conséquence d’opérations simples effectuées de manière constante.

À quoi ressemble « simple » avec PBS

• Surveiller l’utilisation des datastores, le nombre de chunks, les plannings de verify, les plannings de prune.
• Maintenir ZFS en bonne santé : scrubs, SMART, dimensionnement ARC, choix de recordsize.
• Tester les restaurations en restaurant réellement (pas en admirant des tableaux de bord).
• Réplication vers un second PBS ou une cible hors ligne avec contrôle d’accès strict.

Les opérations PBS ressemblent à « opérations de stockage plus une UI de sauvegarde ». C’est bien si vous avez des compétences Linux. C’est mauvais si l’équipe de sauvegarde sait surtout cliquer dans des assistants en espérant qu’ils soient bienveillants.

À quoi ressemble « simple » avec Veeam

• Maintenir les chaînes de sauvegarde, les repositories, les extents SOBR et l’immuabilité.
• Patcher le serveur de sauvegarde et les composants. Garder certificats et identifiants en ordre.
• Surveiller la charge des proxies et les performances de transport (HotAdd vs NBD vs Direct SAN).
• Exécuter des jobs SureBackup / de validation pour ne pas découvrir des restaurations cassées pendant une panne.

Les opérations Veeam ressemblent à « gérer un petit service ». Si vous le faites bien, c’est fluide. Si vous le faites à la légère, ça mord.

Une citation sur la fiabilité qui compte

L’espoir n’est pas une stratégie. — idée paraphrasée couramment attribuée au leadership des opérations (largement utilisée dans la culture de la fiabilité)

Je ne la cite pas mot pour mot outre mesure car l’attribution varie, mais le point est clair : si vous ne pouvez pas décrire votre processus de restauration sans le mot « espoir », vous n’avez pas de processus de restauration.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici les types de vérifications à exécuter quand les restaurations sont lentes ou quand vous concevez pour des restaurations rapides. Chaque tâche inclut : une commande, une sortie réaliste, ce que cela signifie et la décision à prendre.

Tâche 1 : Prouver que le dépôt n’est pas en manque de CPU (PBS)

cr0x@pbs01:~$ lscpu | egrep 'Model name|CPU\\(s\\)|Thread|Core'
CPU(s):                          16
Model name:                      AMD EPYC 7302P 16-Core Processor
Thread(s) per core:              2
Core(s) per socket:              16

Ce que cela signifie : Beaucoup de cœurs pour la compression/le chiffrement et le travail méta. Si vous voyez 2–4 cœurs ici, attendez-vous à ce que les restaurations « donnent l’impression » d’être lentes même avec des disques rapides.

Décision : Si le CPU est faible, augmentez le CPU avant de blâmer les disques. Les magasins de déduplication consomment du calcul, pas seulement de la capacité.

Tâche 2 : Vérifier la marge RAM et le comportement du swap (PBS/Veeam dépôt Linux)

cr0x@pbs01:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            64Gi        18Gi        12Gi       1.2Gi        34Gi        45Gi
Swap:          4.0Gi          0B       4.0Gi

Ce que cela signifie : Bien. « Available » est élevé et le swap est inutilisé. Si le swap est actif, des pics de latence durant les restaurations sont probables.

Décision : Si le swap est utilisé pendant les restaurations, ajoutez de la RAM et ajustez les services gourmands en mémoire. Pour ZFS, vérifiez que l’ARC n’étouffe pas le système.

Tâche 3 : Confirmer la santé du pool ZFS (PBS sur ZFS)

cr0x@pbs01:~$ zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 05:12:44 with 0 errors on Sun Dec 22 03:10:11 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            ata-SSD1                ONLINE       0     0     0
            ata-SSD2                ONLINE       0     0     0
            ata-SSD3                ONLINE       0     0     0
            ata-SSD4                ONLINE       0     0     0

errors: No known data errors

Ce que cela signifie : Scrub propre, aucune erreur de checksum. Si vous voyez des erreurs CKSUM, votre « restauration lente » pourrait en fait être « le matériel ment ».

Décision : Pour toute erreur de checksum : cessez d’optimiser et commencez à remplacer des composants. Les sauvegardes stockées sur un stockage défaillant sont une fiction coûteuse.

Tâche 4 : Surveiller la saturation I/O (les deux)

cr0x@pbs01:~$ iostat -xm 2 3
Linux 6.2.16 (pbs01)  12/28/2025  _x86_64_ (16 CPU)

Device            r/s     w/s   rkB/s   wkB/s  await  %util
nvme0n1          5.2    210.4    980   52240   2.10  48.5
nvme1n1          4.9    208.8    910   51800   2.04  46.9

Ce que cela signifie : Utilisation sous 80% et await ~2ms est sain. Si %util est proche de 100% avec un await en hausse, votre dépôt est le goulot d’étranglement.

Décision : Si saturé : passez à un stockage plus rapide, ajoutez des vdevs, corrigez la disposition RAID, ou séparez les charges à forte metadata sur SSD/NVMe.

Tâche 5 : Vérifier régulièrement l’intégrité du datastore (PBS)

cr0x@pbs01:~$ proxmox-backup-manager datastore verify backup-store
Starting datastore verification...
Checked 124988 chunks, 0 errors, 0 corruptions detected
Verification finished successfully

Ce que cela signifie : Vos données de sauvegarde sont lisibles et cohérentes maintenant, pas seulement « présentes ». La vérification fait la différence entre la confiance et les impressions.

Décision : Si la vérification trouve de la corruption : isolez le stockage, restaurez depuis une réplique/hors site, et traitez cela comme un incident stockage.

Tâche 6 : Inspecter l’état du prune et la réalité de la rétention (PBS)

cr0x@pbs01:~$ proxmox-backup-manager prune-job list
ID   Store        Schedule          Keep Last  Keep Daily  Keep Weekly  Keep Monthly
1    backup-store 02:30             7          14          8            12

Ce que cela signifie : La rétention est explicitement configurée. Si le prune manque ou échoue, les datastores grossissent jusqu’à ce que vous vous en rendiez compte via une panne.

Décision : Si la croissance d’utilisation est inattendue, validez que prune s’exécute et que les « keep » correspondent à la conformité et au calcul de capacité.

Tâche 7 : Confirmer le chemin réseau et les mismatch MTU (les deux)

cr0x@veeamproxy01:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
ens192           UP             00:50:56:aa:bb:cc
ens224           UP             00:50:56:dd:ee:ff

cr0x@veeamproxy01:~$ ip -d link show ens224 | egrep 'mtu|state'
2: ens224: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 state UP mode DEFAULT group default qlen 1000

Ce que cela signifie : Jumbo frames activés sur une interface. C’est correct seulement si tout le chemin le supporte.

Décision : Si les restaurations sont étrangement lentes ou que les retransmissions montent, forcez une cohérence MTU bout en bout (soit tout en 9000 soit tout en 1500) et retestez.

Tâche 8 : Mesurer le débit réel avec iperf3 (les deux)

cr0x@pbs01:~$ iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------

cr0x@esxjump01:~$ iperf3 -c pbs01 -P 4
[SUM]   0.00-10.00  sec  37.5 GBytes  32.2 Gbits/sec                  receiver

Ce que cela signifie : Le réseau n’est pas votre goulot. Si vous obtenez 3–5 Gbits/sec sur un réseau « 10Gb », commencez à chercher des problèmes de switch, d’offloads NIC, ou de congestion.

Décision : Si le débit est bas, réparez le réseau avant de repenser le logiciel de sauvegarde. Ne soyez pas plus malin qu’un câble défaillant.

Tâche 9 : Vérifier la latence disque sur les datastores VMware (axé symptôme)

cr0x@esx01:~$ esxcli storage core device stats get -d naa.600508b1001c3ad5
Device: naa.600508b1001c3ad5
  Successful Commands:  18922301
  Failed Commands:      0
  Read Latency (ms):    3.12
  Write Latency (ms):   18.47

Ce que cela signifie : La latence d’écriture est élevée. Les restaurations qui réécrivent dans ce datastore vont ramper, indépendamment de la vitesse du dépôt.

Décision : Restaurer sur un stockage alternatif (autre datastore/cluster) ou réparer le stockage de production d’abord. Ne versez pas les sauvegardes dans un drain bouché.

Tâche 10 : Identifier le transport du proxy Veeam et les goulots (serveur Windows Veeam)

cr0x@veeam-win:~$ powershell -NoProfile -Command "Get-Service Veeam* | Select Name,Status | Format-Table -Auto"
Name                           Status
----                           ------
VeeamBackupSvc                 Running
VeeamBrokerSvc                 Running
VeeamCatalogSvc                Running
VeeamCloudSvc                  Running

Ce que cela signifie : Les services de base tournent. Si les jobs de restauration bloquent à « Initializing », c’est la première étape : confirmez que les services sont vivants avant de chasser des fantômes de stockage.

Décision : Si les services ne tournent pas, réparez cela d’abord (logs, dépendances, patches). Pas de service, pas de restauration.

Tâche 11 : Valider les options de montage d’immuabilité du dépôt Linux durci (dépôt Veeam Linux)

cr0x@veeamrepo01:~$ mount | grep /backup
/dev/sdb1 on /backup type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,prjquota)

Ce que cela signifie : XFS monté avec project quotas (couramment utilisé dans les schémas de dépôt durci). Si cela manque, l’immuabilité et les contrôles d’espace peuvent ne pas se comporter comme prévu.

Décision : Si les options de montage ne correspondent pas à votre design durci, arrêtez et corrigez. Les fonctions de sécurité non activées ne sont que de la théâtralité.

Tâche 12 : Confirmer l’espace libre du dépôt et la sanity des inodes (les deux)

cr0x@veeamrepo01:~$ df -h /backup
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1        80T   61T   19T  77% /backup

Ce que cela signifie : 77% d’utilisation est généralement acceptable. Beaucoup de systèmes se dégradent près du plein ; les opérations de prune et de merge peuvent provoquer des pics.

Décision : Si vous êtes au-dessus de ~85–90% sur les dépôts, planifiez la capacité avant d’« optimiser ». Tourner près du plein cause de vilaines surprises en restauration.

Tâche 13 : Repérer la perte de paquets et les retransmissions (classique lenteur restauration)

cr0x@pbs01:~$ ss -ti dst :5201 | head -n 12
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0      0      10.10.20.10:5201   10.10.20.50:50944
	 cubic wscale:7,7 rto:204 rtt:0.402/0.033 ato:40 mss:8960 pmtu:9000 rcvmss:536 advmss:8960 cwnd:560 bytes_acked:24389425 segs_out:31233 segs_in:29112 send 99.1Mbps lastsnd:4 lastrcv:4 lastack:4 pacing_rate 198Mbps retrans:12/31320

Ce que cela signifie : Des retransmissions existent. Quelques-unes sont normales ; beaucoup ne le sont pas. La perte transforme un « 10GbE » en « pourquoi ma restauration est encore à 12% ».

Décision : Si les retransmissions augmentent pendant les fenêtres de restauration, inspectez mismatch MTU, erreurs de switch, firmware NIC et congestion.

Tâche 14 : Repérer les réglages ZFS (compression/dataset) qui vous nuisent (PBS)

cr0x@pbs01:~$ zfs get -o name,property,value compression,recordsize tank/pbs
NAME      PROPERTY     VALUE
tank/pbs  compression  zstd
tank/pbs  recordsize   128K

Ce que cela signifie : Valeurs par défaut raisonnables pour de nombreuses charges de sauvegarde. Si recordsize est minuscule, l’overhead métadonnées augmente ; si la compression est désactivée, vous payez en capacité et en I/O.

Décision : Ne « tweakez » pas au hasard. Si la restauration est liée au CPU, testez le changement de niveaux de compression. Si la restauration est liée à l’I/O, évitez les réglages qui font exploser les IOPS.

Tâche 15 : Confirmer la synchronisation temporelle (les catalogues détestent le voyage dans le temps)

cr0x@pbs01:~$ timedatectl status | egrep 'System clock synchronized|NTP service|Time zone'
Time zone: UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active

Ce que cela signifie : L’heure est cohérente. Les points de restauration, la rétention et la validité des certificats peuvent partir en vrille si l’heure dérive.

Décision : Si le temps n’est pas synchronisé, corrigez NTP d’abord. Puis réexaminez les problèmes « mystérieux » de rétention et d’authentification.

Trois mini-récits d’entreprise issus du terrain

1) Incident causé par une mauvaise hypothèse : « Le réseau est OK »

Ils avaient un design propre sur le papier : stockage dépôt rapide, multiples proxies de sauvegarde, et une séparation propre entre VLAN production et sauvegarde. Les restaurations étaient lentes, mais seulement parfois. L’équipe a blâmé la déduplication et la compression, parce que ce sont les parties visibles.

L’hypothèse erronée était subtile : « Si les sauvegardes se terminent la nuit, les restaurations seront rapides. » Les sauvegardes étaient principalement des écritures séquentielles dans le dépôt. Les restaurations étaient des lectures mixtes, plus aléatoires, et plus sensibles à la perte de paquets. Schéma de trafic différent, douleur différente.

Pendant une véritable opération de restauration — une VM applicative avec un RTO serré — le débit a oscillé sauvagement. L’équipe sauvegarde a escaladé vers le stockage, le stockage vers VMware, VMware vers le réseau. Tout le monde est arrivé avec des graphiques. Personne n’avait une mesure unique bout en bout.

Une fois qu’ils ont exécuté des tests iperf3 soutenus pendant la fenêtre de restauration, la vérité est apparue : micro-bursts et pertes de buffer sur un port top-of-rack desservant le dépôt. Ce n’était pas « en panne ». C’était juste punir silencieusement le trafic au pire moment.

Corriger la configuration du port et aligner le MTU bout en bout a fait plus pour le temps de restauration que n’importe quel ajustement de dépôt. La leçon : mesurez le chemin par lequel vous restaurez, pas le chemin que vous espérez avoir.

2) Optimisation qui s’est retournée contre eux : « Dedupe maximale partout »

Un autre site a chassé les économies. Ils étaient fiers de leurs ratios de déduplication. Ils ont tout réglé pour une compression maximale et une déduplication agressive, puis se sont vantés de la réduction de capacité lors des revues trimestrielles. Le dépôt ressemblait à un miracle.

Puis une mise à niveau de cluster est mal passée et ils ont dû restaurer plusieurs VM moyennes rapidement. Les restaurations ont bien démarré puis plafonné. Le CPU du dépôt a été saturé ; les files I/O ont grandi ; la latence est passée de millisecondes à « allez boire un café ».

L’optimisation était mathématiquement correcte et opérationnellement mauvaise : leur matériel de dépôt était dimensionné pour l’ingest des sauvegardes, pas pour la réhydratation de restauration à grande échelle. La compression maximale signifiait un coût CPU maximal juste quand ils avaient besoin de débit.

Ils ont corrigé cela de manière ennuyeuse : réduit les niveaux de compression, augmenté le CPU, et séparé les charges afin que les VM à fort changement ne partagent pas le même goulot que les cibles de restauration critiques. La déduplication est restée bonne. Les restaurations sont devenues prévisibles.

Conclusion : optimisez d’abord pour le RTO, ensuite pour l’efficacité de stockage. Personne ne gagne une panne en présentant des ratios impressionnants.

3) Pratique ennuyeuse mais correcte qui a sauvé la situation : tests de restauration réguliers

Une organisation avait la réputation d’être ennuyeuse. Contrôle des changements. Fenêtres de patch. Documentation étonnamment à jour. Chaque mois, ils exécutaient des tests de restauration : une restauration complète de VM, une restauration de fichier, une restauration d’élément applicatif, et un test de « restauration sur réseau alternatif ».

Ce n’était pas glamour. Ce n’était pas optionnel non plus. Ils traitaient les tests de restauration comme des exercices incendie : vous ne les annulez pas parce que le bâtiment n’a pas brûlé récemment.

Quand un rançongiciel a frappé une unité métier, le plan d’intervention était déjà ancré. Ils ont restauré les systèmes critiques dans un segment réseau isolé, validé l’intégrité, puis planifié la réintégration. Le calendrier n’a pas été « héroïque ». Il a été régulier.

Ils ont quand même perdu du temps. Tout le monde en perd. Mais ils n’ont pas perdu le fil. Pas d’improvisation, pas de « quelqu’un se souvient du mot de passe du dépôt ? », pas de découverte frénétique de pilotes manquants.

C’est ce que l’opération simple vous achète : moins de surprises. En crise, l’ennui est une fonctionnalité.

Mode d’emploi pour un diagnostic rapide

Quand les restaurations sont lentes, vous n’avez pas le temps d’être philosophique. Vous devez trouver le goulot en 15 minutes, pas après le postmortem.

Premier : déterminez où vous êtes lent (lecture, écriture ou calcul)

• Le dépôt est-il saturé en lecture ? Vérifiez iostat -xm sur le dépôt pendant la restauration. Cherchez un %util élevé et un await en hausse.
• L’écriture en production est-elle saturée ? Vérifiez la latence du datastore sur ESXi. Une écriture élevée signifie « restaurer dans du sable mouvant ».
• Le CPU est-il saturé ? Vérifiez le CPU sur le dépôt et le proxy/serveur de sauvegarde. Un CPU utilisateur élevé pendant la restauration signifie souvent décompression/chiffrement.

Second : confirmez que le réseau ne vous trompe pas

• Exécutez iperf3 entre les réseaux source et destination de la restauration.
• Vérifiez les retransmissions avec ss -ti (Linux) et les compteurs de ports switch si disponibles.
• Validez le MTU bout en bout. Un MTU mixte est un classique échec « ça marche mais lentement ».

Troisième : vérifiez la chaîne de sauvegarde et la santé des métadonnées

• Pour PBS : exécutez les schedules de verify du datastore et cherchez des erreurs ; assurez-vous que le prune n’est pas bloqué et que le stockage n’est pas proche du plein.
• Pour Veeam : confirmez les services, la disponibilité du repository, et que la chaîne de jobs n’est pas dans un état étrange (p. ex. incréments corrompus, extents manquants).

Quatrième : isolez avec un test de restauration contrôlé

• Restaurez une seule VM sur un stockage/réseau alternatif.
• Comparez le débit avec la restauration en production pour prouver si le datastore de destination est le coupable.
• Mesurez. Ne devinez pas.

Erreurs courantes (symptômes → cause racine → correction)

1) Symptomatique : « L’instant recovery est instant… mais douloureusement lent »

Cause racine : Le stockage du dépôt est optimisé pour l’ingest séquentiel des sauvegardes, pas pour les lectures aléatoires nécessaires pour faire tourner des VM.

Correction : Placez les workloads « instant run » sur des médias rapides (NVMe/SSD), sur des extents séparés, ou acceptez que l’instant recovery soit un outil de triage, pas un état d’exécution à long terme.

2) Symptomatique : la vitesse de restauration varie énormément d’un jour à l’autre

Cause racine : Congestion réseau, perte de paquets, ou un système de stockage partagé avec des voisins bruyants.

Correction : Mesurez le débit pendant les fenêtres de restauration (iperf3), vérifiez les retransmissions, implémentez QoS ou isolez le trafic de sauvegarde, et évitez de restaurer dans un datastore occupé.

3) Symptomatique : les sauvegardes réussissent, les restaurations échouent à cause de corruption ou de points manquants

Cause racine : Absence de vérification régulière ; erreurs de stockage sous-jacent ; chaînes cassées.

Correction : PBS : planifiez datastore verify et scrubs ; remplacez les disques défaillants. Veeam : activez les health checks, des fulls/ synthétiques périodiques avec vérification, et exécutez des tests de restauration.

4) Symptomatique : le dépôt se remplit « inattendu » et les jobs échouent

Cause racine : Mauvaise configuration de rétention/prune, nettoyage désactivé, ou fenêtres d’immuabilité dépassant la planification de capacité.

Correction : Auditez la rétention et l’immuabilité, vérifiez les opérations prune/merge, imposez des seuils de capacité et des alertes avant 85–90% d’utilisation.

5) Symptomatique : les snapshots VMware grossissent et les VM stun pendant les fenêtres de backup/restore

Cause racine : La suppression de snapshot est lourde pour le stockage ; longues chaînes de snapshots dues à des lectures de backup lentes ; problèmes CBT ou de quiescence.

Correction : Améliorez le débit de lecture de backup (mode de transport, placement des proxies), gardez les snapshots de courte durée, et investiguez les paramètres de quiescence VM/app.

6) Symptomatique : « On a restauré, mais l’application est cassée »

Cause racine : Sauvegardes crash-consistent alors qu’une cohérence applicative était requise, ou dépendances manquantes (DNS/AD/synchro temporelle).

Correction : Utilisez le traitement application-aware quand nécessaire, documentez l’ordre des dépendances, et validez la récupération applicative lors des tests de restauration.

7) Symptomatique : l’équipe sécurité dit que les sauvegardes ne résistent pas aux rançongiciels

Cause racine : L’infrastructure de sauvegarde partage les identifiants admin avec la production, les dépôts sont supprimables, ou l’immuabilité n’est pas réellement appliquée.

Correction : Séparez les identités, appliquez immuabilité / dépôts durcis, restreignez l’accès shell, et maintenez une copie hors ligne/hors site avec des identifiants indépendants.

Listes de contrôle / plans étape par étape

Plan A : Si vous choisissez Veeam et voulez des restaurations rapides sans drame

1. Concevez pour la restauration, pas pour la sauvegarde. Choisissez un stockage de repository capable de gérer des lectures aléatoires (SSD/NVMe aide).
2. Choisissez le placement des proxies intentionnellement. Évitez « un proxy VM sur l’hôte surchargé ». Utilisez plusieurs proxies si la concurrence compte.
3. Standardisez le mode de transport. Testez HotAdd vs NBD vs Direct SAN dans votre environnement et documentez le gagnant.
4. Construisez l’immuabilité correctement. Schémas de repository Linux durci, identifiants séparés et accès strict. Pas d’admin de domaine partagé.
5. Fixez des SLO opérationnels. Exemple : « Restaurer une VM tier‑1 en X minutes en conditions de test. »
6. Automatisez les tests de restauration. Utilisez des jobs de vérification et des drills complets périodiques. Faites-en un événement calendrier, pas une humeur.
7. Alertez sur la santé du dépôt. Espace libre, échecs de jobs et comportement inhabituel des chaînes. Attrapez-le avant la panne.

Plan B : Si vous choisissez PBS comme dépôt de sauvegarde et voulez des opérations simples

1. Surestimez légèrement disques et RAM. Les magasins de déduplication aiment la RAM et des IOPS cohérents.
2. Utilisez ZFS comme un adulte. Scrubs planifiés, monitoring SMART, ashift raisonnable, et pas de « contrôleur RAID mystère » pratiquant le write‑hole.
3. Planifiez verify et prune. Faites des checks d’intégrité routiniers, pas héroïques.
4. Séparez les domaines de défaillance. Répliquez vers un autre PBS ou une cible de stockage indépendante. Évitez « même rack, même switch, même alimentation ».
5. Documentez les runbooks de restauration. Exactement comment restaurer vers VMware, y compris identifiants, réseau, et où atterrissent les VM restaurées.
6. Testez les restaurations mensuellement. VM complète, niveau fichier, et au moins une procédure de récupération spécifique à une application.
7. Limitez le rayon d’action des admins. Les admins sauvegarde ne devraient pas être les mêmes comptes qui peuvent tout supprimer instantanément.

Plan C : Approche hybride qui gagne souvent

Si vous êtes pragmatique (bonne chose), vous remarquerez ceci : Veeam et PBS n’ont pas à s’exclure mutuellement. De nombreuses équipes réussissent avec :

• Veeam pour l’orchestration native VMware et les workflows de restauration.
• Discipline stockage Linux/ZFS/PBS pour les repositories : vérifications d’intégrité, performances prévisibles, principes d’immuabilité.

Même si PBS n’est pas votre orchestrateur principal VMware, vous pouvez apprendre de sa philosophie : verify, prune, checksum, répliquer et garder la simplicité.

FAQ

1) Lequel est plus rapide en restauration : PBS ou Veeam ?

Veeam est plus rapide pour « réussir à remettre quelque chose en marche » dans de nombreuses entreprises VMware parce qu’Instant VM Recovery est mature. PBS peut être extrêmement rapide pour remettre les données quand le pipeline est bien conçu. La réponse pratique : Veeam l’emporte sur les modalités de restauration ; PBS l’emporte sur le comportement de stockage prévisible quand il est correctement construit.

2) Quel est le plus grand prédicteur unique de performance de restauration ?

La performance de lecture du dépôt sous I/O aléatoire plus la latence d’écriture du datastore de production. Si l’un ou l’autre est mauvais, les restaurations seront mauvaises. Les fonctions ne vous sauveront pas.

3) Puis‑je obtenir une résilience contre les rançongiciels avec les deux ?

Oui, mais il faut l’implémenter. Veeam utilise couramment des repositories Linux durcis et des fenêtres d’immuabilité. PBS supporte la vérification d’intégrité et peut être déployé avec des contrôles d’accès stricts et la réplication vers une cible isolée. Le point faible est souvent l’identité et l’accès, pas le logiciel.

4) Pourquoi les restaurations échouent-elles quand les sauvegardes « ont réussi » ?

Parce que « job de sauvegarde success » signifie souvent « données déplacées », pas « données restaurables ». Vous avez besoin de vérification (PBS verify / scrubs ZFS) et de tests de restauration réguliers (vérification Veeam / SureBackup) pour attraper les échecs silencieux.

5) La déduplication vaut‑elle toujours le coup pour les sauvegardes VMware ?

Généralement oui pour la capacité, mais elle peut nuire à la performance de restauration si CPU et IOPS ne sont pas dimensionnés pour la réhydratation. Si votre RTO est strict, considérez des réglages moins agressifs de compression/dedupe ou du compute/stockage plus rapide sur le dépôt.

6) Dois‑je restaurer vers le même datastore ?

Seulement si le datastore est sain. Si la latence d’écriture est élevée, restaurer dessus est de l’auto‑sabotage. Restaurez vers un stockage alternatif, validez le boot de la VM, puis migrez quand l’environnement est stable.

7) Quelle est la défaillance opérationnelle la plus courante avec Veeam ?

La prolifération : trop de proxies/repositories configurés sans normes, plus un patching et une hygiène des identifiants incohérents. Vous obtenez un système puissant mais difficile à comprendre pendant un incident.

8) Quelle est la défaillance opérationnelle la plus courante avec PBS ?

Sous‑estimer l’ingénierie du stockage. Les gens le traitent comme une boîte magique de déduplication et le déploient sur des disques médiocres, des contrôleurs RAID douteux ou du matériel sous‑dimensionné. PBS vous dira la vérité — en étant lent.

9) Ai‑je besoin de 10GbE (ou plus) pour des restaurations rapides ?

Si vous avez de grosses VM et un RTO strict, oui — au moins 10GbE, souvent plus. Mais la bande passante sans faible perte et MTU cohérent est un tigre en papier. Mesurez le débit et les retransmissions pendant les fenêtres de restauration.

10) Comment rendre les opérations de restauration « simples » pour l’astreinte ?

Écrivez un runbook avec : où les restaurations atterrissent, comment valider la santé du boot/app, qui approuve le placement réseau, et ce que signifie « terminé ». Puis exécutez des drills mensuels. La simplicité se forme, elle ne s’achète pas.

Prochaines étapes concrètes

1. Choisissez votre workflow de restauration principal. Si vous avez besoin de boot instantané depuis les sauvegardes comme action standard, favorisez Veeam.
2. Benchmarkez votre chemin de restauration. Exécutez iperf3, vérifiez iostat du dépôt et la latence du datastore ESXi. Réparez le lien le plus lent en premier.
3. Implémentez la vérification. PBS datastore verify + scrubs ZFS, ou health checks Veeam plus tests de restauration programmés. Rendez‑le routinier.
4. Concevez l’immuabilité et le contrôle d’accès délibérément. Séparez les identifiants, réduisez le rayon d’action, et gardez au moins une copie hors de portée d’une identité de production compromise.
5. Faites un drill de restauration complète ce mois‑ci. Pas une restauration de fichier. Pas une capture d’écran. Une vraie VM qui boote avec une check‑list de validation.

Si vous voulez la recommandation directe : la plupart des environnements VMware devraient démarrer avec Veeam pour la sécurité opérationnelle, puis appliquer la discipline à la PBS pour la couche dépôt. Si vous exploitez déjà fortement Linux/stockage et que vous privilégiez un cœur de sauvegarde plus simple, PBS peut être un choix propre, rapide et préservant la santé mentale — tant que vous concevez l’intégration VMware et testez les restaurations sérieusement.