Discussion :

[FMJ]

Bonjour,

Je rencontre de temps en temps l'erreur suivante lors de l'exécution d'un job faisant une sauvegarde différentielle d'une base toutes les heures (sur 12h). Une sauvegarde complète est réalisée toutes les nuits (sans aucun problème).

Ce qui me trouble, c'est que la survenance de l'erreur est aléatoire en terme de jour, mais quelle se passe principalement à la même heure (12h25 en l'occurrence). La sauvegarde différentielle précédente (11h25) ne génère jamais d'erreur, ni la sauvegarde suivante (13h25) .

Impossible d'effectuer une sauvegarde différentielle de la base de données "PROD", car il n'existe pas de sauvegarde de la base de données actuelle. Effectuez une sauvegarde complète en réexécutant BACKUP DATABASE sans l'option WITH DIFFERENTIAL. [SQLSTATE 42000] (erreur 3035) BACKUP DATABASE s'est terminé anormalement. [SQLSTATE 42000] (erreur 3013). L'étape a échoué.

Le job exécute simplement :
BACKUP DATABASE BASE TO DISK = @FileName WITH INIT, COMPRESSION, FORMAT, STATS=5, CHECKSUM, DIFFERENTIAL

Date de survenance :
30/10 (dimanche 12h25)
23/10 (dimanche 12h25)
14/08 (dimanche 12h25)
05/07 (mardi 10h25 ....)
16/05 (lundi 10h25)
.....

Si vous avez une idée, merci d'avance.

[SQLpro]

Une sauvegarde différentielle ne prends en compte que les différences de mises à jour effectuée depuis la dernière sauvegarde complète. S'il n'y a pas eu de sauvegarde complète, l'opération est impossible...

Je me demande si votre base ne serait pas recréée régulièrement ?

Vérifiez la date de création de cette base...

A +

[FMJ]

Bonjour et merci pour votre réponse.
La date de création est en 2019 (une restauration je pense car la base a réellement été créée en 2008 !).
Ce que je ne comprends pas, c'est que la sauvegarde différentielle précédente (1h avant) et celle d'après (1h plus tard) se passe sans problème.
Et pour rappel, la sauvegarde complète est effectuée toutes les nuits (sans aucun souci).

[janlouk]

Voilà ce que je trouve sur google et c'est souvent pareil :

https://www.stellarinfo.com/blog/sql...ng-abnormally/

What Causes SQL Server Error 3013?
Plausible reasons that result in SQL Server restore database is terminating abnormally error are as follows:

An attempt to view the Network drive has been made by an unauthorized user.
The storage device, on which the backup file (.bak) is stored, has failed.
A write failure has occurred during backup creation.
When there is not enough storage on the backup drive.
When an attempt is made to execute backup on transactional logs when Database is in SUSPECT mode.

https://www.sqlservercentral.com/blo...ing-abnormally

[FMJ]

La cause est indiquée dans le message d'erreur : " il n'existe pas de sauvegarde de la base de données actuelle"
Le problème, c'est que la sauvegarde complète existe bien et est parfaitement accessible : elle est créée localement (avant d'être sauvegardée en réseau). Et je ne vois pas pourquoi ce disque local ne serait pas accessible à ce moment précis ?

[SQLpro]

Que vaut @FILENAME ?

Faite le tests sur un storage local

A +

[FMJ]

Je viens juste de répondre ci-dessus : la cible du BACKUP est un disque local. Aucune raison qu'il soit offline à ce moment là (ni à aucun autre moment d'ailleurs).

[SQLpro]

Que reste-t-il comme place sur ce disque ? Avez-vous regardé dans les journaux d'événement ? Est-ce un disque compressé ?

A +

[FMJ]

Oui. Il reste pas mal de place sur ce disque local dédiée à la sauvegarde locale.
Par contre je vous ai dit une bêtise plus haut : la sauvegarde complète se fait localement mais les différentielles sont enregistrées sur un mapping réseau (qui en fait est quasi local car le disque cible se trouve sur un VM hébergée sur le Hyper-V et les 2 VM partagent le même vSwitch). Mais quand BACKUP rencontre une erreur d'enregistrement, le message d'erreur n'est pas le même.
Et rien d'anormal sur les évènements système.

Ce qui me turlupine, c'est pourquoi cette erreur est si rare (allez toutes les 400 sauvegardes à peu près) et pourquoi elle survient aux même heures (pour le pas dire à la même 12h30) ?! Mystère ....

[KyoshiroKensei]

Bonjour,

Est qu'un job de backup de la vm ne passe pas à 12h25?? J'ai déjà eu quelques conflits lorsque SQL tente d'accéder aux disques d'une vm en cours de sauvegarde à cause du VSS imposé.

Egalement, est ce que la rétention de la sauvegarde complète couvre bien la plage de sauvegarde différentielle?

[FMJ]

Bonjour
Merci pour vos réponses.
Concernant la plage de sauvegarde, la réponse est oui. La preuve : les sauvegardes différentielles précédente et suivante ne génèrent pas d'erreur, alors qu'il n'y a pas d'autre sauvegarde complète dans l'intervalle.

Concernant une "opération de sauvegarde" parallèle, oui il y a une réplication de la VM SQL Server sur la même période (toutes les 1/2h). Donc potentiellement oui pourquoi pas un conflit VSS encore qu'il y aurait un message système sous Windows le signalant + c'est aussi le cas pour toutes les autres sauvegardes différentielles, or celles-ci ne posent pas problème.
Je vais quand même décaler l'horaire de ces sauvegardes afin que cela ne soit plus concomitant.
..............
Maintenant que tu en parles et en regardant plus près, je m'aperçois que cette réplication dure habituellement 6-7min. Or au même moment qu'il y a l'erreur de sauvegarde, la réplication dure anormalement de 11 à 15min. C'est le cas pour les erreurs des 30/10, 23/10 et 14/07. Pas du 05/07.
J'ai vérifié : il n'y a pas d'opération particulière de déduplication ou autre sur ce créneau horaire (d'ailleurs cela n'est pas proposé pour une réplication).
Je vais ouvrir un ticket Veeam pour comprendre pourquoi cette inflation de la durée de la réplication et comment il peut y avoir un impact sur la sauvegarde SQL Serveur (conflit VSS ?).
En tout cas du point de la vue du fonctionnement du SQL Server, aucun impact sensible en production !

[KyoshiroKensei]

Je suis aussi sous Veam, nous avons du désactiver la contrainte VSS sur certains serveur SQL car il y a avait un conflit avec SQL lors de l'accès des aux disques. Peut être le début d'une piste. Tu devrais avoir des messages dans les logs SQL si c'est bien cela du type "..IO freeze during XXX seconds)"

Je n'ai pas pensé à la déduplication qui à aussi un lourd impact.

Vérifie aussi si tu n'a pas un snap qui serait actif sur ta Vm. Avec le temps, le snap a un impact sur les performances.

[FMJ]

Oui il y a 24 points de contrôle qui couvre 24h.
J'avais déjà noté que ce nombre de points entraînait un accroissement très significatif du temps de traitement de la réplication. Après investigation avec le support Veeam, cela vient d'une seule requête WMI très coûteuse en temps qui était répétée pour chaque point de contrôle. De mémoire pour quelques points de contrôle, la réplication durait 1-1.5min, alors qu'avec 24 points ça dure 6-7min.
Veeam ferait bien de convertir ses requêtes WMI en Powershell !!!

Par contre ce que je ne comprends pas, c'est pourquoi le pb se pose aléatoire mais précisément à 12h25, alors que la concomitance réplication Veeam - backup SQL Server se produit 20 fois dans la journée ?
Le problème s'est d'ailleurs reproduit ce midi ...

J'ai ouvert un ticket, je reviendrai donner la version du support Veeam.

[SQLpro]

Je suis aussi sous Veam, nous avons du désactiver la contrainte VSS sur certains serveur SQL car il y a avait un conflit avec SQL lors de l'accès des aux disques. Peut être le début d'une piste. Tu devrais avoir des messages dans les logs SQL si c'est bien cela du type "..IO freeze during XXX seconds)"

Je n'ai pas pensé à la déduplication qui à aussi un lourd impact.

Vérifie aussi si tu n'a pas un snap qui serait actif sur ta Vm. Avec le temps, le snap a un impact sur les performances.

Désactiver VSS c'est la garantie que vos sauvegardes par SNAHSOT de VM seront irrécupérables. Ne jamais faire.

Notez que VEAM ou les snapshots de VM sont incompatible avec AlwaysOn. En effet le freez des fichiers est considéré comme un blocage de la base (s'en est réellement un) et donc déclenche le basculement automatique...

A +

[KyoshiroKensei]

Bonjour,

Je suis en accord avec vous, cependant, dans notre cas nous ne sauvegardons pas l'intégralité de la Vm, mais uniquement le disque qui contient les backups. Donc couper le VSS n'est pas un problème.