Comment Tina sauvegarde les VMs Windows sous VMware

[olivier covasParticipant]

Depuis toujours Time Navigator respecte les règles de sauvegardes fournis par VMware en utilisant les fonctionnalités misent à notre disposition dans les librairies VMware VDDK.

Toutes nos sauvegardes HV VMware s’appuient depuis toujours sur les quiesce snapshot permettant de garantir des sauvegardes et restaurations cohérentes à nos clients.

Je vais vous décrire le schéma fonctionnel d’une sauvegarde Quiesce effectué par notre produit Time Navigator :

– lors du déclenchement d’une sauvegarde HV VMware, une requête sécurisée (certificat SHA1 du vCenter) est faite auprès du vCenter pour déterminer la liste et les caractéristiques des VMs constituant le datacenter VMware à sauvegarder.

– à travers le VMware Vddk, nous soumettons au vCenter une requête de sauvegarde d’une ou plusieurs VM(s).

Cette requête peut être parallélisée pour sauvegarder simultanément plusieurs VM dans des environnements SAN ou VSAN. La sauvegarde des VM(s) dans des environnements NSX est maintenant prise en charge.

– la requête de sauvegarde est déléguée par le vCenter à l’ESX qui héberge la VM à sauvegarder.

– l’ESX, à travers les VMware Tools installés dans la VM Windows, énumère les plugins VSS afin de définir quelles applications sont installées dans la VM (active Directory, MS SQL, Exchange, Sharepoint, et toutes autres applications disposant de Writer VSS).

>cela équivaut à la commande Microsoft: VSS list writers

–  à la suite de cette verification, l’ESX à travers les VMware Tools, effectue un snapshot “Quiesce” en sollicitant tous les writers VSS se trouvant dans la VM à sauvegarder

Remarque : si l’un des Writers VSS n’est pas fonctionnel, le Quiesce VMware ne sera pas réalisé avec succès, donc la sauvegarde Time Navigator vous remontera une erreur sur cette VM en particulier.

Example :

* Lors du Quiesce d’une VM Windows 2019, avec SQL Server installé, on a pu voir dans l’observateur d’événements Windows une erreur du type event id : 513  :

Log Name: Application

Source: Microsoft-Windows-CAPI2

Event ID: 513

Task Category: none

Level: Error

System Error:

Access is denied.

La correction de cette erreur, en utilisant la technote ci-dessous, a permis de corriger les erreurs de quiesce VMware :
https://docs.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/event-id-513-vss-windows-server

– Lorsque le Quiesce snapshot est effectué avec succès, le vCenter tente de présenter le Datastore (où se trouve le snapshot) au proxy HV VMware via le SAN si le proxy dispose d’un attachement SAN et que le zoning a été fait.

– Si le proxy HV VMware est une VM, le mode “hotadd” est utilisé (similaire au SAN à l’intérieur de l’infrastructure VMware).

– Si le proxy HV VMware ne dispose pas d’attachement SAN (pas de contrôleur HBA) ou si l’attachement SAN est perdu, l’ESX transférera les données via le réseau (mode NBD) via le port TCP 902 vers le proxy HV VMware

Remarque :

Si l’infrastructure VMware est en mode VSAN, nous pouvons utiliser un mode multi proxy HV VMware pour utiliser le mode “hotadd” pour toutes les sauvegardes, conformément au prérequis VMware.

Variable TINA_VCB_VIRTUAL_HOST

– Lorsque Time Navigator a lu toutes les données (mode SAN ou hotadd) ou a reçu toutes les données (mode NBD), il demande la suppression du snapshot au vCenter.

Spread the love

[Auteur]

Messages