Audit des sauvegardes Veeam : la réalité face à la criticité des VM

« Tout est sauvegardé. » C’est la réponse que j’obtiens presque toujours quand je pose la question en début de mission. Elle est rarement fausse au sens strict : il y a bien des jobs Veeam, ils tournent, la console est majoritairement verte. Ce qui manque, c’est la preuve que chaque VM est protégée à la hauteur de ce qu’elle représente pour le métier, et une documentation qui décrit la stratégie réelle plutôt que celle d’il y a trois ans.

On a rarement le temps d’avoir quelque chose à jour. Les équipes d’exploitation ont le nez dans le quotidien, et la documentation des sauvegardes passe toujours après l’incident du jour. C’est pour ça que je ne pars plus des documents existants. Je pars des paramètres réellement positionnés et des comptes rendus réellement produits.

Le principe : auditer la configuration réelle, pas la documentation

Un audit de sauvegarde classique commence par des entretiens et la lecture des procédures. C’est utile pour comprendre l’intention, mais ça ne dit rien de ce qui tourne vraiment. Les écarts se cachent précisément entre ce qui a été prévu et ce qui a été paramétré, puis modifié au fil des migrations, des urgences et des changements d’équipe.

Je construis donc des scripts d’audit qui interrogent directement les outils : Veeam pour la configuration des jobs et l’historique des sessions, vSphere pour l’inventaire des VM. Les données brutes sont ensuite croisées, et c’est là que l’IA intervient pour produire rapidement un rapport lisible qui met en avant la réalité des sauvegardes.

Extraire la configuration Veeam

Le module PowerShell de Veeam Backup & Replication donne accès à tout ce qu’il faut. Pour chaque job, je récupère les objets protégés, la planification, la rétention, la présence d’une copie secondaire et le dépôt cible :

Import-Module Veeam.Backup.PowerShell

$jobs = Get-VBRJob | Where-Object { $_.JobType -eq 'Backup' }
$protection = foreach ($job in $jobs) {
    foreach ($objet in $job.GetObjectsInJob()) {
        [pscustomobject]@{
            VM        = $objet.Name
            Job       = $job.Name
            Actif     = $job.IsScheduleEnabled
            Retention = $job.Options.BackupStorageOptions.RetainCycles
            Depot     = $job.GetBackupTargetRepository().Name
        }
    }
}

Les objets d’un job sont parfois des dossiers, des tags ou des datastores plutôt que des VM nommées. Le script doit alors résoudre ces conteneurs en liste de VM, sinon une VM ajoutée dans un dossier sauvegardé paraîtra non protégée alors qu’elle l’est, ou l’inverse.

La configuration ne suffit pas : un job actif peut échouer tous les soirs. J’ajoute donc l’historique des sessions sur 30 jours, avec Get-VBRBackupSession et le détail par VM via les sessions de tâches. On obtient pour chaque VM la date du dernier point de restauration réussi et le taux d’échec sur la période.

Extraire l’inventaire vSphere

Côté VMware, PowerCLI fournit la liste exhaustive des VM, leur état, leur dossier, leurs tags et leur taille :

Connect-VIServer vcenter.exemple.local
$vms = Get-VM | Select-Object Name, PowerState,
    @{n='Dossier';e={$_.Folder.Name}},
    @{n='Tags';e={(Get-TagAssignment -Entity $_).Tag.Name -join ', '}},
    @{n='Go';e={[math]::Round($_.UsedSpaceGB)}}

Si les VM portent déjà un tag de criticité ou d’application, c’est idéal. Sinon, le dossier ou une convention de nommage donnent souvent un premier découpage, à valider ensuite avec les responsables métier.

Le croisement VM par VM

Avec ces deux extractions, chaque VM de l’inventaire est confrontée à sa protection réelle :

• est-elle dans au moins un job actif ?
• quand date son dernier point de restauration réussi ?
• quelle est la fréquence de sauvegarde et la rétention ?
• existe-t-il une copie hors site ou immuable ?
• la restauration a-t-elle déjà été testée, et quand ?

Ces réponses sont ensuite comparées à la criticité de la VM. Une matrice simple suffit, à trois ou quatre niveaux, avec pour chacun un RPO (la perte de données acceptable) et un RTO (la durée d’interruption acceptable). Une VM critique avec un RPO de quatre heures ne peut pas se contenter d’une sauvegarde quotidienne, et encore moins hebdomadaire.

Les écarts que l’on trouve presque à chaque fois

Certains reviennent si souvent qu’ils sont devenus ma liste de contrôle :

• la VM oubliée après une migration : déplacée vers un nouveau cluster ou renommée, elle est sortie du périmètre du job sans que personne ne s’en rende compte ;
• la VM critique en sauvegarde hebdomadaire : configurée ainsi au départ, quand elle ne l’était pas encore ;
• le job en échec chronique : il échoue une nuit sur trois depuis des mois, les alertes sont filtrées ou partent dans une boîte que personne ne lit ;
• la copie hors site absente ou non immuable : la sauvegarde existe, mais sur le même site, voire sur un dépôt accessible depuis le domaine, donc exposé à un rançongiciel ;
• les VM éteintes jamais nettoyées : elles consomment de la rétention pour des machines qu’on ne restaurera jamais ;
• la restauration jamais testée : personne ne sait combien de temps prendrait la remise en service d’une application complète.

Le rôle de l’IA : un rapport en quelques heures au lieu de plusieurs jours

Une fois les données extraites et croisées, il reste à les rendre lisibles. C’est l’étape qui prenait auparavant le plus de temps : mettre en forme, rédiger les constats, prioriser, écrire les recommandations. Avec l’IA, à partir des tableaux produits par les scripts, je génère rapidement un rapport structuré : synthèse pour la direction, tableau des écarts par niveau de criticité, détail technique par VM, plan d’action.

Je relis chaque constat. L’IA rédige bien et vite, mais elle ne connaît ni l’histoire du SI ni les contraintes du métier. Elle ne décide pas non plus de la criticité d’une application : c’est une décision qui appartient au client, que j’aide à formaliser. Les données envoyées pour la rédaction sont limitées aux tableaux nécessaires, anonymisés si besoin.

Le livrable : enfin une documentation à jour

Le même travail produit ce qui manque presque toujours :

1. la stratégie de sauvegarde telle qu’elle est réellement appliquée ;
2. la matrice des VM par criticité, avec RPO, RTO et protection associée ;
3. les procédures de restauration, VM par VM pour les plus critiques ;
4. un plan de reprise d’activité qui s’appuie sur ces éléments, et non l’inverse.

Et comme tout part de scripts, l’audit se rejoue. Relancé chaque trimestre, il montre ce qui a dérivé depuis la dernière fois, sans repartir de zéro.

Cette approche fait partie de mon expertise infrastructure et de ma façon d’utiliser l’IA appliquée à l’infrastructure. Si vous n’êtes pas certain de pouvoir restaurer vos VM critiques dans les délais attendus, parlons-en.