L’utilisation par défaut de VEEAM backup combiné à SQL Server détruit vos journaux de transactions… Le saviez-vous ?
Et cela empêche de récupérer l’intégralité de votre base de données après un crash !
Par défaut lorsque vous utilisez VEEAM backup pour sauvegarder vos serveurs de base de données, les instances MS SQL Server voient leurs journaux de transactions détruits, ce qui vous interdit de récupérer vos bases de données au plus proche de l’incident en cas de désastre… Pour un outil censé protéger vos données c’est quand même une stratégie suicidaire et imbécile dont on est en droit de se demander si les ingénieurs de VEEAM qui ont conçu cette aberration sont des suppôts de l’islamiste ou des hackers à la solde de Poutine…
À sujet du « vidage » des journaux de transactions des bases de données par VEEAM qui est une mauvaise pratique, voici quelques lecture croustillantes :
- Log shipping always failing with NUL
- Veeam (VM tool) SQL Server Backup did not Shrink the Transaction Log
- SQL logs and Veeam
Ce qu’il faut comprendre c’est que par défaut, VEEAM, lorsqu’on lui demande de sauvegarder les bases MS SQL Server, effectue une sauvegarde des données des bases, mais vide les journaux de transactions de toutes les bases. Toutes les transactions encore reproductibles et qui ont eu lieu depuis la dernière sauvegarde sont irrémédiablement perdues. Elles seraient pourtant bien utile car le journal permet de compléter les bases des toutes dernières transactions effectuées afin de ne rien perdre ou minimiser la perte de données…
En effet, SQL Server dispose de 3 modes de sauvegardes :
- FULL (complète) la base au niveau des données
- DIFFERENTIAL (différentielle) les données modifiées dans la base depuis la dernière complète (à réserver à de très grosses bases – plusieurs To)
- LOG (transactionnelle) les transactions ayant eut lieu dans la base depuis n’importe quelle sauvegarde précédente.
Ainsi que de quelques options pour les très grosses bases, notamment par fractionnement du stockage (sélection de fichiers ou groupes de fichiers…)
Ordinairement on effectue une sauvegarde complète par jour et de nombreuses transactionnelles au cours de la journée. Par exemple avec une complète à 2h du matin et des transactionnelles toutes les 20 minutes, il est alors possible de reconstituer les bases avec une perte moyenne de 10 minutes.
En outre, si le serveur SQL est encore atteignable, et même si des bases sont corrompues ou invisible dans l’IHM, il est peut être encore possible de forcer une sauvegarde des journaux de transaction des bases en mode d’urgence (BACKUP LOG … WITH NO_TRUNCATE…). Grace à cette ultime récupération des transactions, il sera possible, lors de la restauration, d’appliquer successivement tous les sauvegardes transactionnelles à la restauration de la complète afin de n’avoir perdu aucune donnée, et récupérer les bases à l’ultime point de leur écriture…
Malheureusement, VEEAM empêche cela… voir page 10 de ce doc la configuration imbécile et par défaut de VEEAM : SQL Server Backup and Restore in a Veeam environment
En conclusion, pour éviter que deux systèmes (les sauvegardes faites par SQL Server et celles faites par VEAAM) ne se croissent et interfèrent au niveau des sauvegardes des bases de données (et qu’on ne sache plus lesquelles utiliser pour restaurer…) ne jamais activer les sauvegardes des bases par VEEAM et laisser la maintenance SQL Server (Agent SQL dans les éditions Web, Standard ou Enterprise et tâches planifiées de Windows pour la version Express) effectuer les sauvegardes directement.
Pour information SQL Server ne fait jamais de DUMP (qui sont en fait des extractions de données tables et nécessite des verrous – comme c’est le cas de MySQL, MariaDB ou PostGreSQL) mais exécute des copies binaires des pages de données (structure de 8 Ko prise de la RAM si en cache, sinon du disque) sans aucun blocage, ce qui est plus rapide, plus sûr et plus efficace…
Toutes les sauvegardes effectuées dans SQL Server et sans aucune exception (y compris celles de VEEAM), sont tracées en interne dans la base de données msdb dans les tables systèmes dbo.backup… On peut donc savoir quelles sont les bases cibles des sauvegardes, quand cela a t-il été fait et ou cela est-il stocké… Mais VEEAM masque certains de ces informations pour obliger la restauration à passer par son interface…
Et même si vous effectuez des sauvegardes transactionnelles par VEEAM en plus de celle de SQL Server, le fait de superposer différentes sauvegardes par différents moyens, brise la chaine de sauvegarde (chainage des « Log Segment Number » ou LSN) ce qui ne permet pas de reprendre l’intégralité des données des bases et peut même les corrompre… Alors que les sauvegardes régulières des journaux de transaction permettent de récupérer l’intégralité des bases jusqu’au point de rupture…
En bref, préférez ce que fait naturellement SQL Server plutôt que de passer par une surcouche VEEAM qui ne fait que lancer les commandes SQL Server en vous obligeant à maintenir deux systèmes au lieu d’un et complexifier la reprise en cas de désastre !
Fred Brouard/SQLpro, expert bases de données relationnelles SQLpro@SQLspot.com
* Le site sur les SGBD relationnels et le SQL : https://sqlpro.developpez.com *
* le blog SQL, SQL Server, SGBDR... sur : https://blog.developpez.com/sqlpro/ *
* Expert Microsoft SQL Server MVP (Most valuable Professional) pendant 14 ans *
* Entreprise SQL SPOT : modélisation, conseil, audit, optimisation, formation *
* * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
*** Et pour un séjour à Toulon, pensez au 16e ciel ! ***