Restauration d’un contrôleur de domaine virtuel grâce à Veeam

Si la problématique de la sauvegarde de contrôleurs de domaine et surtout de leur restauration fut un temps épineuse, ce n’est plus tellement le cas de nos jours, grâce à des avancées côté Windows et côté outils de sauvegarde.

Dans le cadre d’un contrôleur de domaine virtuel, si réaliser un snapshot avant d’installer des mises à jour Windows par exemple peut partir d’un bon sentiment, c’est la catastrophe assurée en cas de retour en arrière, toute la cohérence de l’annuaire étant remise en question puisque le DC sera incapable de comprendre pourquoi il se voit présenter des mises à jour venant du futur puisqu’il aura été restauré à un état passé comme si rien ne s’était passé depuis la création du snap. L’outil Windows Server Backup peut être un bon point de départ pour la sauvegarde d’AD ; cependant l’emplacement de stockage n’est peut-être pas toujours défini à l’avance et l’outil peut ne pas s’intégrer dans les politiques de sauvegarde de l’infrastructure générale.

Récemment, j’ai pu effectuer sur une plateforme de tests la sauvegarde et la restauration de contrôleurs de domaines virtualisés sous vSphere ESXi grâce à Veeam Backup & Replication. Dans cet article, je vais aborder les points principaux d’une telle manipulation si un contrôleur de domaine ne démarre plus (et que par conséquent, la structure de l’AD est intacte), sans oublier de rappeler qu’il est indispensable de valider sur des environnements iso ces procédures de sauvegarde et restauration, en plus d’avoir connaissance de la documentation Veeam à ce sujet (p. ex. ces deux articles : ici et ). Dans le cas où la cohérence même de l’annuaire a été remise en question
(corruption, par exemple), d’autres étapes peuvent être requises
(je pense notamment par un passage par le DSRM) mais je ne les aborderai pas dans cet article.

La plateforme de test est composée de 4 machines : 3 contrôleurs de domaine 2012 R2 et un client Windows 10, sous vSphere 6.5 et sauvegardée par Veeam Backup & Replication en version 9.5.

Tout d’abord, il est important de vérifier que le job de sauvegarde des DC ait l’option Enable Application-aware Processing d’activée.

Bien sûr, avant de s’engager dans plus de manipulations, il sera bienvenu de s’assurer que les sauvegardes ont été réalisées avec succès en temps et en heures.

Suite à des manipulations sur dc03, j’obtiens un célèbre BSOD :

Ce DC doit donc être restauré. Dans VMware, je vais procéder à sa mise hors-tension, et à la suppression de la VM.

Dans Veeam, je vais procéder à la restauration de la VM, en utilisant les options Entire VM Restore puis Instant Recovery.

Je choisis de restaurer la VM to the original location, sans connecter le réseau ni directement démarrer la VM. Une fois cette opération terminée, la VM sera ajoutée dans VMware et stockée sur le pool de sauvegarde Veeam ; il faut la déplacer sur le stockage de production.

En allant sur Instant Recovery dans Veeam, je peux sélectionner mon dc03 et choisir Migrate to Production.

Une vérification des paramètres s’impose pour être sûr de finaliser la récupération au bon endroit, puis le déplacement sur l’environnement de production s’effectue.

Une fois l’opération terminée, je sélectionne l’option Stop Publishing sur dc03. Ainsi, il disparaît de VMware où il apparaissait en double : en tant que dc03 (fraîchement restauré) et dc03-xxxxx (la restauration de Veeam avant son déplacement sur l’environnement de production). Il ne reste donc plus que dc03.

Un petit tour dans les paramètres de la VM pour confirmer que tout est bien configuré : ne pas oublier de connecter la carte réseau avant de la démarrer.

Windows va s’initialiser puis redémarrer au bout de quelques minutes – c’est normal.

En réalité, Windows démarre en mode sans échec, se resynchronise avec les autres contrôleurs de domaine, réalise des mises à jour de fichiers de configuration avant de redémarrer. Une fois ce redémarrage terminé, l’OS est utilisable et répond aux requêtes AD comme si rien ne s’était passé. Tout le processus est entièrement automatique et géré par Veeam, qui lors de la sauvegarde, applique certains paramètres en détectant que la VM est un DC Windows.

Il ne reste plus qu’à réaliser quelques tests grâce à dcdiag et repadmin :

Un dcdiag /a /i devrait tout de même renvoyer quelques erreurs systèmes qui ont été journalisées dans l’event viewer en fonction de la manière dont le DC a planté mais tous les autres tests devraient être en succès, pour peu qu’ils l’aient été pré-crash. D’autres tests comme la jonction de stations aux domaine doivent toujours fonctionner sans anicroche.

Veeam et Powershell : état des jobs de sauvegardes sur les dernières 24 heures

Afin de me faciliter la tâche sur certains contrôles quotidiens, j’ai développé un script Powershell pour Veeam Backup & Replication me permettant d’afficher rapidement si il y a eu des échecs de sauvegarde durant les dernières 24 heures.

Ce script est plutôt simple et contrôle les sauvegardes de machines virtuelles VMware (supporte également Hyper-V il me semble) ainsi que les agents Veeam déployés sur des machines Windows. Veeam possède diverses commandes Powershell pour les divers types de sauvegarde qu’il propose (sauvegarde sur bande, par exemple) ; si il y a besoin de contrôler d’autres types de sauvegarde, alors il suffit simplement de réaliser une requête supplémentaire Get-VBRxSessionx sera évidemment remplacé par le type de sauvegarde.

J’ai testé ce script sur Veeam B&R version 9.5.

Add-PSSnapin VeeamPSSnapIn
Disconnect-VBRServer
$SrvList = @("backupsrv1","backupsrv2","veeamdev1","veeamdev2")
Write-Host "Veeam B&R Daily Checks Jobs Script"

function process{
param($type)
if($session.Result -eq "Failed"){
switch ($type){
"std" { $name = $session.Name ; $RetryList = $sessionList | Where { $_.Name -eq $name } }
"agent" { $job = Get-VBREPJob -ID $session.JobId ; $name = $job.Name ; $RetryList = $sessionAgentList | Where { $_.JobId -eq $session.JobId } }
}
$status = $session.Result
$st = $session.CreationTime
$et = $session.EndTime
$global:count+=1
echo "Job: $name"
echo "Status: $status"
echo "Start Time: $st"
echo "End Time: $et"
foreach($Retry in $RetryList){
if ($Retry.Result -ne "Failed"){
if ($Retry.State -ne "Running"){
$st = $Retry.CreationTime
$et = $Retry.EndTime
echo "Job $name finally succeeded."
echo "Start Time: $st"
echo "End Time: $et"
}
if ($Retry.State -eq "Running"){
echo "Job $name currently running."
}
}
}
}
}

foreach($UniqueSrv in $SrvList){
Write-Host "Processing server $UniqueSrv"
Connect-VBRServer -Server $UniqueSrv
$SessionList = Get-VBRBackupSession | ?{($_.EndTime -ge (Get-Date).AddHours(-24) -or $_.CreationTime -ge (Get-Date).AddHours(-24))}
$SessionAgentList = Get-VBREPSession | ?{($_.EndTime -ge (Get-Date).AddHours(-24) -or $_.CreationTime -ge (Get-Date).AddHours(-24))}
$global:count = 0
foreach($session in $SessionList){
process("std")
}
foreach($session in $SessionAgentList){
process("agent")
}
if ($global:count -eq 0){ Write-Host "No errors detected in the jobs for this server." }
Disconnect-VBRServer
}

Merci à smasterson d’avoir partagé un script complet de reporting Veeam en HTML, dont j’ai repris le pipe pour la condition des 24 dernières heures, mon premier développement de script fonctionnant autrement, cette syntaxe est plus propre. La documentation de Veeam étant ni claire ni complète et l’interface avec Powershell particulièrement catastrophique (propriétés, variables et retours différents entre deux objets pour rien, d’où l’usage de switch et gestion des états de fin de traitement anarchique : certaines sauvegardes s’arrêtent sans retour, d’autres en succès en fonction de leur type), j’ai donc dû m’y prendre à plusieurs fois avant de proposer un script fonctionnel.

Impossibilité de se connecter à Veeam après un changement de nom de machine

J’ai récemment été confronté à la situation où après un remplacement de serveur de sauvegarde fonctionnant sous Veeam Backup & Replication entraînant un changement de nom, je ne pouvais plus me connecter même en local.

La console ne peut pas se connecter car le service Veeam Backup Service n’est pas démarré. Il accepte de se lancer, mais se coupe aussitôt.

La solution se trouve dans le registre, où Veeam stocke en dur le nom de la machine lors de l’installation. Fatalement, lorsqu’il change par la suite, les deux valeurs ne concordent plus, et le service ne peut s’exécuter.

Il faut aller chercher dans HKLM\SOFTWARE\Veeam, les clefs Veeam Backup and Replication et Veeam Backup Catalog. Ces deux clefs contiennent une entrée chacune avec l’ancien hostname.

La valeur de SqlServerName doit être votre nom de serveur, p. ex. « srv-veeambkp »
Ici, le hostname fait partie d’un chemin. Par exemple, la valeur sera « \\srv-veeambkp\VBRCatalog ».

L’information est disponible sur ce fil de discussion sur les forums Veeam, merci au contributeur d’avoir exposé la solution.