Datafly.pro

Prenons l'exemble d'un plan de sauvegarde SQL Server organisé comme suit :

• Sauvegarde complète chaque nuit
• Sauvegarde différentielle le matin et le midi
• Sauvegarde de journaux de transaction toutes les heures.

Jusque là tout va bien, je peux restaurer ma base de données en suivant mon cycle de sauvegarde, et la positionner à n'importe quelle heure de la journée. Par exemple, s'il est 16 heures, je restore :

• Ma sauvegarde complète de la nuit
• Ma sauvegarde différentielle de midi
• Mes 4 journaux de transaction de 13h, 14h, 15h, 16h. (Savez-vous d'ailleurs qu'avec ce même jeu de sauvegardes, je pourrais choisir de restaurer à 15h30 avec l'option STOPAT ?)

Mais patatras : peu après la sauvegarde complète de SQL Server, l'agent VEAM vient faire sa sauvegarde de la machine. Et dans cette opération, il lance aussi une sauvegarde complète des bases de données, en mode snapshot (VSS).

• Premier problème, par défaut, la sauvegarde complète faite par VEAM, n'est pas une sauvegarde de copie (COPY_ONLY) : elle vient donc s'inscrire dans notre beau cycle de sauvegarde.
  • De ce fait, la sauvegarde différentielle de midi s'appuie sur cette sauvegarde VEAM, et non plus sur la sauvegarde SQL Server. Notre sauvegarde différentielle ne pourra pas être restaurée, elle a besoin de la sauvegarde complète sur laquelle elle s'appuie.

Msg 3136, Niveau 16, État 1, Ligne 9
Impossible de restaurer cette sauvegarde différentielle car la base de données n'a pas été restaurée à un état précédent valide.
Msg 3013, Niveau 16, État 1, Ligne 9
RESTORE DATABASE s'est terminé anormalement.

• Deuxième problème, VEAM propose dans ses options de tronquer les journaux de transactions : si cette option est activée, il va lancer, tout de suite après son backup complet, une commande BACKUP LOG [nom_de_la_base] TO DISK = 'NUL'. Cela vide le journal sans conserver de fichier de sauvegarde.
  • Conséquence, encore pire : aucune des mes sauvegardes de journal ne pourra plus être restaurée. Le cycle de sauvegardes de journal a été rompu, comme si l'on avait effacé la première des sauvegardes de journal (on l'a envoyée vers NUL...)

Msg 4305, Niveau 16, État 1, Ligne 10
Le journal dans ce jeu de sauvegarde commence au numéro de séquence d'enregistrement 43000000038900001, ce qui est trop récent pour une application à la base de données. Une sauvegarde de fichier journal antérieure qui inclut le numéro de séquence d'enregistrement 43000000034600001 peut être restaurée.
Msg 3013, Niveau 16, État 1, Ligne 10
RESTORE LOG s'est terminé anormalement.

On peut bien sûr encore restaurer notre sauvegarde complète de la nuit précédente, mais toutes les sauvegardes suivantes de la journée sont bonnes à mettre à la poubelle ! Etes-vous prêt à revenir à la veille ?

Un petit exemple d'analyse du journal de sauvegarde d'une base où on trouve ces deux problèmes :

Côté VEAM, voici l'option à modifier impérativement (si vous tenez à garder quand même les bretelles avec la ceinture) ! On doit pouvoir trouver la même option avec d'autres agents de sauvegarde : si l'option n'existe pas et que les sauvegardes ne sont pas faites avec l'option COPY_ONLY, n'utilisez pas cet agent de sauvegarde !

Si la sauvegarde est COPY_ONLY, la sauvegarde VEAM n'interfère plus avec notre plan de sauvegarde, CQFD.

Par ailleurs, d'une manière générale, les sauvegardes de snapshot ont une facheuse tendance à figer les IO, et si c'est un peu long il y a parfois des effets pervers : comme par exemple de fortes attentes, des timeout, voire même des failover Always On intempestifs. J'ai plusieurs fois rencontré ces problèmes avec VEAM. Donc les bretelles avec la ceinture peuvent nous poser encore d'autres soucis...

Et on ne le dira jamais assez, inutile d'avoir un beau plan de sauvegarde si vous ne testez jamais la restauration...!