Rends-moi mon Storage Block !

On a été confronté à un problème de restauration avec Veeam Backup assez tordu sur une sauvegarde en mode reversed incremental que l’on voulait partager avec vous.

A la base, bien sûr, une demande urgente de restauration de machine virtuelle (nommée CADILLAC) depuis un des points de sauvegarde incrémentale (ie pas le dernier point FULL de sauvegarde) pour une cause obscure, et là, gros message d’erreur un peu effrayant :

Le problème s’est posé avec une restauration de fichiers vmdk, une restauration de la VM complète, une restauration de fichier in-guest via FLR ou même en Instant Recovery

On avait bien sûr aucun problème avec la sauvegarde, la vérification d’intégrité ne retournant pas d’erreur et le job de backup se terminant correctement.

Ce qui était bizarre, c’est qu’une restauration de cette VM avec le dernier point de sauvegarde (sauvegarde FULL via le fichier .vbk) passait correctement, mais dès que l’on essayait de restaurer depuis des points antérieurs (sauvegarde incrémentale via les fichiers .vrb), l’erreur apparaissait, et cela pour toutes les VM du même job …

Même en passant par l’outil extract.exe, le résultat était le même :

En regardant dans les fichiers de log du job de restoration (fichier VmFilesRestoreJob_Restore_CADILLAC_Files.log situé, pour Windows 2008 R2, dans C:\Users\<compte de service>\AppData\Local\Veeam\Backup), nous avons isolé le message d’erreur :

Info [AP] (Client) error: The sizes of the standard snapshot block [524288] and standard storage block are different [1048576].

Le paramétrage de la taille de bloc du job était bien à 512 KB, et cela depuis pas mal de temps (en recherchant rapidement avec Notepad++ dans tous les fichiers journaux des job de backup, on a bien la même taille de bloc à 512KB) mais plus moyen de savoir ce qui avait été configuré au tout début :

Pour rappel, la taille de block est définie par le paramétrage suivant sur le job de backup :

Comme le rappelle ce WhitePaper http://www.veeam.com/hp-protection-vmware-infrastructure.html

Setting the storage target to a WAN target results in a block size of 256 KB, 512 KB for LAN targets and 1 MB for locally attached targets.

Après avoir ouvert un incident chez Veeam, ils nous ont demandé de confirmer le problème en exportant des journaux directement via le shell de VeeamAgent.exe

Cela se fait en lançant l’exécutable VeeamAgent.exe (que l’on peut trouver dans C:\Program Files\Veeam\Backup and Replication) et ensuite tapper les commandes suivantes :

dumpStg
chemin du fichier de sauvegarde
chemin du fichier de journal contenant les metadata qui sera créé

Note: cette commande fonctionne aussi bien avec les fichiers .vbk que .vrb

C’était la première fois que l’on manipulait VeeamAgent.exe directement en ligne de commande et la commande dumpStg qui extrait les metadata des fichiers de sauvegardes pour les exporter dans un fichier journal nous était inconnue, mais visiblement on n’est pas les seuls à ne pas la connaitre, une recherche rapide dans Google sur les mots clé « veeam dumpStg » ou sur les forums de Veeam nous rassure un peu :p

Par contre il faut prévoir suffisamment de place, les fichiers générés étant un peu volumineux (comptez près de 400 Mo de journaux de metadata pour un fichier de sauvegarde d’un peu plus d’1 To).

Après analyse des metadata générées par dumpStg, on voit effectivement une différence dans la taille des blocs :

Storage: e:\XXX_CHASSIS_20\XXX_CHASSIS_20.vbk
 Storage format
     Standard block size: 1048576

Storage: e:\XXX_CHASSIS_20\XXX_CHASSIS_202012-07-06T210152.vrb
 Storage format
     Standard block size: 524288

Cela explique donc le problème de restauration: la taille de bloc du fichier VBK n’est pas égale à la taille de bloc de fichiers VRB, donc on peut bien restaurer depuis les fichiers VBK, mais quand on essaie de réunir la chaine VBK+VRB pour effectuer une restauration depuis un VRB, le problème se pose.

Il a donc du y avoir une modification de la configuration du job de sauvegarde pour passer de Local Target (1MB) à LAN Target (512KB) sans qu’on réalise que cela poserait problème, vu que la sauvegarde continuait à bien se passer, et que l’on ne restore pas tous les jours non plus…

Veeam nous a confirmé qu’il s’agissait d’un bug de la version 5, qui est visiblement corrigé dans la version 6.1 (mais il faut que le job soit créé depuis la version 6.1, nous avons essayé d’importer notre job sur un Veeam 6.1, le problème reste le même).

Attention donc à ne pas changer la taille de bloc d’un job de sauvegarde Veeam Backup 5 si des sauvegarde existent déjà sous peine de casser la chaine VBK/VRB et donc de rendre impossible certaines restaurations.

Laisser un commentaire

Required fields are marked *.