Discussion :

[FMJ]

Bonjour,
Hier soir j'ai dû faire face à un sinistre majeur sur notre infra serveur, avec au bout restauration du SQL Server.
Jusqu'à là, pas de problème majeure, la restauration hard et système s'est bien passée.
Par contre au moment de restaurer une base particulière, aucun souci avec la restauration du backup full mais erreur pour celle du backup diff :

Full :
FirstLSN 2495271000000010000000
LastLSN 2495271000000010000000
CheckpointLSN 2495271000000010000000
DatabaseBackupLSN 2494922000000030000000
BackupStartDate 20/12/2022 23:15
BackupFinishDate 20/12/2022 23:16

Diff :
FirstLSN 2495346000000010000000
LastLSN 2495346000000010000000
CheckpointLSN 2495346000000010000000
DatabaseBackupLSN 2495276000000010000000
BackupStartDate 21/12/2022 09:25
BackupFinishDate 21/12/2022 09:25

Le message d'erreur est : "Message 3136, niveau 16, état 1, serveur xxxxxxx, ligne 1
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.
Message 3013, niveau 16, état 1, serveur xxxxxx, ligne 1
RESTORE DATABASE s'est terminé anormalement."

L'erreur est logique car on voit bien que le DatabaseBackupLSN (2495276000000010000000) du Diff ne correspond pas au CheckpointLSN du Full(2495271000000010000000). Le souci, c'est qu'il n'y a pas d'autre backup full entre les deux ???????!!!! Or si je lis bien, le 2495276 du diff laisse entendre qu'il y a un full plus récent que le 2495271 du full de référence. Mais ce n'est pas le cas ....

Sur le même serveur, j'ai fait un test sur une autre base :
> backup full + modif des données + backup diff + modif des données
> puis restore full norevovery --> OK
> puis restore diff revovery --> OK
Et dans ce cas le DatabaseBackupLSN du Diff correspondait bien au CheckpointLSN du Full.

Comme il fallait repartir ce matin, les données ont été passées par profit et perte....
Mais pour l'avenir, auriez-vous une idée sur l'origine de cette erreur et de cet écart de LSN ? Merci

[SQLpro]

Dans le serveur original, il aurait fallut lister les différentes sauvegardes effectuées depuis les tables de msdb (dbo.backupset, dbo.backupmediaset) Il est possible qu'une sauvegarde full ait été effectuée entre temps... Avez-vous un hébergeur qui aurait procédé de son propre chef à cela ? Ou bien un développeur qui aurait voulu avec une copie fraiche de la base ?

Dans tous les cas il y a eu une sauvegarde FULL effectué entre la FULL que vous avez eu et la diff que vous présentez...

A +

[FMJ]

Je suis la seule personne qui ait la main sur ce serveur et cette instance.
J'ai bien vérifié : il n'y a qu'un seul job de l'agent qui puisse réaliser une sauvegarde full de la base --> c'est celui de 23h15 !
Par contre vers 00h30, il y a une sauvegarde Veeam, avec l'option application aware processing activée pour SQL server. Ce mécanisme prépare les applis concernées pour un "consistent backup". Je crains que Veeam n'enregistre son backup comme un backup SQL serveur.
Je vais faire un test pour vérifier.

[SQLpro]

Je suis la seule personne qui ait la main sur ce serveur et cette instance.
J'ai bien vérifié : il n'y a qu'un seul job de l'agent qui puisse réaliser une sauvegarde full de la base --> c'est celui de 23h15 !
Par contre vers 00h30, il y a une sauvegarde Veeam, avec l'option application aware processing activée pour SQL server. Ce mécanisme prépare les applis concernées pour un "consistent backup". Je crains que Veeam n'enregistre son backup comme un backup SQL serveur.
Je vais faire un test pour vérifier.

Bien entendu !

C'est pourquoi il faut INPERATIVEMENT désactiver les sauvegardes VEEAM qui posent plus de problèmes qu'ils n'en résolvent...

Il y a beaucoup de problème avec VEEAM en général, par exemple c'est franchement pas compatible avec AlwaysOn du fait qu'il freeze les fichiers des bases pour faire son snapshot, ce que AlwaysOn considère comme une panne de service de la BD !
https://www.reddit.com/r/Veeam/comme...th_backing_up/
https://communities.vmware.com/t5/ES...m/td-p/2851019
https://support.severalnines.com/hc/...napshot-backup

VEEAM essaye même de cacher cela à ses clients en noyant le web d'article à la gloire de VEEAM et AlwaysOn SQL Server afin que les moteurs de recherche repoussent les cas exposé de problème en queue de liste google...

A +

et n'oubliez pas de sauvegarder msdb...

[FMJ]

Après tests, je peux vous confirmer :
> Un backup Veeam sans "application aware processing" n'a pas d'impact sur les indicateurs LSB de sauvegarde de SQL Server
> Un backup Veeam avec "application aware processing" modifie les indicateurs LSB de sauvegarde de SQL Server

Mais ce n'est pas la faute de Veeam, simplement la mienne :
> je n'ai pas assez creusé ce sujet auprès de Veeam
> j'ai fait des tests de restauration "salle blanche" qui marchaient très bien
> mais pas des tests terrain sur la base des sauvegardes nocturnes, en tentant compte de l'ordonnancement dans lequel elles étaient exécutées.

Il fallait juste en être conscient : je vais désormais prendre les mesures correctives nécessaires ....

Merci pour votre aide.

[SQLpro]

mais à quoi sert de faire deux sauvegardes différentes qui se télescopes ? ça n'a pas de sens !

A +