Pourquoi est-il si important de sauvegarder votre journal des transactions?

Nous mettons actuellement en œuvre une solution de sauvegarde pour un client et leur solution ERP utilise SQL Server.

La solution ERP a été mise en place par une autre entreprise. Et ils me disent qu'il est super important de sauvegarder et de tronquer le journal des transactions.

J'ai lu un peu sur ce journal des transactions et je ne comprends pas pourquoi c'est si important quand je sauvegarde déjà la machine entière de toute façon (nous utilisons ArcServe UDP, qui connaît SQL Server et utilise VSS). Je crois comprendre que les tâches de nettoyage sur la machine virtuelle SQL Server se chargent déjà de tronquer le journal, cependant, UDP permet également la troncature du journal SQL Server.

Je crois comprendre que le journal des transactions peut être utilisé pour restaurer des bases de données corrompues, car il s'agit bien d'un journal de toutes les transactions. Mais j'ai déjà une sauvegarde toutes les heures de la base de données, alors, pourquoi m'en soucierais-je?

Vous ne devez le faire que si votre mode de récupération de base de données est défini sur "complet". S'il est défini sur "simple", vous n'avez pas besoin de faire une sauvegarde du journal des transactions. Mais attention à la différence entre ces deux options!

Tout d'abord: si vous voulez pouvoir restaurer la base de données à un moment précis, vous devez utiliser le mode "complet". (Je pense que vous pouvez régler le timing de manière si précise que vous pouvez même spécifier les millisecondes pour le point de restauration) En mode "simple", vous ne pouvez revenir qu'à la dernière sauvegarde complète .

Si vous ne sauvegardez / tronquez pas votre journal des transactions, il augmentera tout le temps (en mode complet). J'ai vu des bases de données où le fichier .trn était plus de deux fois plus gros que la base de données elle-même. Cela dépend de la fréquence à laquelle des modifications ont été apportées à la base de données.

Un autre point est qu'une sauvegarde de journal est normalement plus rapide qu'une sauvegarde complète.

Je pense donc que votre plan de sauvegarde pour effectuer une sauvegarde complète toutes les heures n'est pas optimal. Mais cela dépend de votre situation:

Si vous dites: D'accord, si je peux restaurer la base de données à la dernière heure complète, tout va bien. -> Vous pouvez également penser à définir le mode de récupération sur "simple" si vous souhaitez conserver la sauvegarde complète toutes les heures.

À mon avis, une meilleure idée serait de faire une sauvegarde complète tôt le matin, puis de faire une sauvegarde du journal des transactions toutes les heures. Cela devrait être beaucoup plus rapide et vous pouvez restaurer à tout moment de votre choix. Et aussi votre fichier .trn ne grandira pas trop ...

J'espère que cela t'aides.

Bien. Vous vous souciez parce que si votre modèle de récupération est défini sur complet et que vous ne sauvegardez pas le journal des transactions à l'aide de la sauvegarde SQL (et non la sauvegarde du serveur), le journal des transactions continue de croître jusqu'à ce qu'il consomme tout l'espace disque disponible. (J'ai vu une fois un collègue inférieur installer SQL Server sur le lecteur système et ne jamais sauvegarder le journal des transactions. Il a mangé Windows .)

Oui, il sera également restauré à un moment précis. Jusqu'à la minute. Comme le dit Twinkles, oui, les gens abandonnent des tables et autres.

Je ne sais pas ce que vous utilisez pour votre sauvegarde horaire de la base de données entière, et si c'est le même produit que ce que vous utilisez pour la machine entière. Si tel est le cas, une solution de sauvegarde non compatible SQL n'est pas prise en charge pour les restaurations. Le temps nécessaire à VSS pour copier les fichiers MDF et LDF peut provoquer une incompatibilité d'horodatage interne, par exemple.

Nous gérons également plusieurs systèmes ERP. Et le problème est souvent que la nuit, il y a souvent des travaux par lots de longue durée qui synchronisent les données avec d'autres systèmes. Et cela prend parfois une heure ou plus. Donc, ce que vous voulez faire en cas de crash, c'est de sauter à un point où vous avez des données cohérentes. (Ce qui signifie juste entre deux travaux par lots.) Si vous ne regardez que l'heure, il se peut que vous ne sachiez pas toujours exactement quel était l'état de la base de données à ce moment.

Mais bien sûr, cela dépend de la situation. Si vous n'avez pas de travaux automatisés, etc., tout va bien avec une sauvegarde toutes les heures.

Il y a plusieurs raisons pour lesquelles vous souhaitez le faire:

1. Un système de base de données est généralement occupé, effectuant peut-être des milliers de transactions par seconde. Les données peuvent être réparties sur plusieurs fichiers sur différents systèmes de fichiers. Il n'est pas trivial de s'assurer que la base de données est dans un état cohérent (aka utilisable) après la restauration. Si votre solution de sauvegarde est à la hauteur, tant mieux, mais il vaut mieux en être sûr avant de parier votre travail dessus.
2. Un exemple: quelqu'un laisse tomber une table avec des données importantes par erreur. Si vous disposez d'une sauvegarde de base de données avec une capacité de récupération ponctuelle, vous pouvez restaurer les données rapidement, sans avoir à restaurer l'ensemble du système.
3. Si la base de données est en mode de récupération complète, le journal des transactions de SQL Server augmentera. L'espace de stockage dans le journal des transactions n'est réutilisé que si le journal des transactions a été sauvegardé. Si vous ne sauvegardez pas régulièrement le journal des transactions, votre système de fichiers se remplira jusqu'à ce qu'il ne reste plus d'espace. À ce moment, tout s'arrêtera immédiatement , car aucune nouvelle transaction ne pourra être lancée.

Lorsque votre base de données se développe au-delà de ce que vous pouvez sauvegarder en une heure, vous avez besoin d'un modèle différent.

Une sauvegarde complète de votre base de données tronquera vos journaux, mais elle doit être «compatible avec SQL», car dans ce scénario, c'est le logiciel de sauvegarde qui indique au serveur SQL ce qu'il a sauvegardé et ce qu'il doit tronquer.

Comme d'autres le mentionnent, si vous avez une base de données dans le modèle de récupération «complet», son journal de transactions augmentera indéfiniment, jusqu'à ce que vous effectuiez une sauvegarde intégrant SQL.

La récupération est vraiment le problème ici, pas la sauvegarde. Et ce n'est pas une décision technique, c'est une décision commerciale!

Si les propriétaires de votre entreprise acceptent de perdre une heure ou plus de leurs transactions de base de données (ce qui peut être TRÈS difficile ou impossible à refaire!), Alors votre modèle fonctionne. S'ils sont OK avec le système en panne pendant des heures pendant que vous restaurez la base de données entière à partir de la sauvegarde, alors votre modèle fonctionne.

Cependant, si votre entreprise considère son système ERP comme un atout essentiel pour son fonctionnement (n'est-ce pas tous?), La définition d'un temps de récupération maximum acceptable (aka RTO, objectif de temps de récupération) pour vos services critiques sera une décision commerciale.

En outre, les propriétaires d'entreprise ou les parties prenantes du système doivent définir la quantité de données qu'ils sont prêts à risquer de perdre dans un incident, également appelé RPO (Recovery Point Objective).

La réponse si vous leur posez la question pourrait être "AUCUNE donnée ne peut être perdue! Le système ERP doit être disponible 24/7/365!" ... dont nous savons tous qu'il est très peu probable qu'il soit rentable. Si vous leur présentez le coût associé à la construction d'un tel système entièrement redondant et non-stop, ils trouveront un chiffre plus raisonnable ..;)

Le fait est que si vous pouvez éviter de perdre des transactions, vous économisez potentiellement des centaines ou des milliers d'heures de travail perdues. Cela représente des ÉNORMES économies dans n'importe quelle entreprise et croît avec la taille de votre entreprise ...

Tout le monde a eu d'excellentes réponses à cela, mais j'aimerais ajouter une autre note importante ... ou deux.

Connaître les particularités des modèles de récupération SQL Server et les exigences de votre entreprise en matière de perte de données sont tous deux très importants; cependant, dans ce cas, il est impératif que vous compreniez comment votre produit de sauvegarde fonctionne avec SQL Server. (D'après les commentaires ci-dessus, il semble que vous sauvegardiez des volumes de disque via une copie VSS, ce qui signifie que des sauvegardes SQL Server peuvent ou non être requises en plus.)

Ayant récemment évalué un produit similaire, certains des points importants que vous pourriez avoir à poser sont:

• Comment les restaurations sont-elles effectuées à un moment donné pour une base de données en récupération complète?
• Comment la sauvegarde initiale est-elle gérée pour une nouvelle base de données en récupération complète?
• Le produit de sauvegarde nécessite-t-il des sauvegardes de journaux SQL Server pour restaurer à un moment donné? (Dans mon cas, la réponse était oui.)
• Votre infrastructure de stockage peut-elle gérer le volume de données pour les copies / différentiels VSS (à un intervalle donné) en plus de la charge SQL normale?

J'espère que cela vous sera utile.

L'expérience de mon équipe avec notre récente évaluation a fourni des réponses très intéressantes aux questions ci-dessus. Une chose est sûre, les sauvegardes sont plus complexes pour nous avec un produit de sauvegarde VSS.

Comme beaucoup d'autres l'ont déjà dit, si vous utilisez un outil tiers pour sauvegarder / prendre une photo de la machine virtuelle ou du stockage, vous courez toujours le risque de ne pas avoir de sauvegarde valide. Tous les outils tiers qui gèrent les sauvegardes SQL Server implémenteront et se connecteront à SQL Server à l'aide de VSS. Il le fait pour demander à SQL Server de suspendre toutes les E / S dans les fichiers de données afin qu'un instantané cohérent puisse être pris. Sinon, vous pouvez avoir de nombreuses transactions dans différents états et une restauration ne saura pas si ces transactions peuvent être déplacées vers l'avant ou vers l'arrière.

Je n'ai pas travaillé avec tous les outils d'instantanés VM / Storage tiers, mais ceux avec lesquels j'ai travaillé n'ont jamais pu créer d'instantanés de stockage là où se trouvaient les bases de données système - SQL Server ne peut pas mettre ces bases de données au repos. Ils ont TOUS sauvegardé ces bases de données de manière en continu - c'est-à-dire ... en émettant les commandes BACKUP DATABASE puis en claquant le fichier de sauvegarde lui-même.

En plus de cela, comme beaucoup l'ont également dit, si vous êtes dans le modèle de récupération COMPLET et que vous n'émettez pas régulièrement d'instructions BACKUP LOG, le journal des transactions continuera de croître jusqu'à ce qu'il n'y ait plus de place sur le disque.

La vraie question que vous devez vous poser, et je l'ai peut-être manquée ci-dessus ... avez-vous réussi à restaurer à partir de ces sauvegardes un certain nombre de fois, et êtes-vous satisfait de la cohérence des données dans ces restaurations. Personnellement, même cela ne me suffirait pas, cela ressemble toujours à un lancer de dés, et c'est quelque chose qu'un bon DBA ne prend jamais en matière de sauvegarde et de récupération.

Reconnaissez que les journaux de transactions ne sont pas simplement un mécanisme de récupération. Une bonne maintenance des journaux peut également jouer un rôle essentiel dans les performances globales de la base de données (c'est-à-dire le débit des transactions).

La sauvegarde fréquente de vos fichiers journaux fait plusieurs choses:

1. Il réduit le nombre de VLF dans les fichiers journaux physiques, ce qui est bon pour les performances.
2. Vous êtes mieux préparé à utiliser les sauvegardes de journaux au cas où vous auriez besoin de récupérer une base de données.
3. C'est un peu plus rapide qu'une sauvegarde complète

Si vous parvenez à effectuer une sauvegarde complète toutes les heures, vous ne savez pas combien vous bénéficieriez de sauvegardes de journaux plus fréquentes. Après tout, si je comprends bien, une sauvegarde complète sauvegardera également autant de journaux que nécessaire afin d'assurer une restauration complète.

D'un autre côté, si votre application génère des tonnes de transactions entre vos sauvegardes complètes toutes les heures, cela pourrait expliquer pourquoi les développeurs d'origine ont suggéré une maintenance plus détaillée des journaux. De nombreuses transactions peuvent augmenter le nombre de VLF dans vos journaux, ce qui peut entraîner une baisse des performances jusqu'à ce que le journal soit tronqué. J'ai vu cela exprimé comme une erreur de «délai d'expiration de la requête» dans une application (peu de temps avant son blocage).

Les recommandations relatives à la maintenance du journal des transactions sont très bien décrites dans cet article 8 étapes pour améliorer le débit du journal des transactions . De plus, cet article Top Tips for Effective Database Maintenance mentionne un nombre VLF quelque peu arbitraire à viser (<200), ce qui a très bien fonctionné pour moi.

D'autres personnes ont déjà donné la plupart des raisons d'une sauvegarde translog etc. Il semble y avoir un doute quant à la raison pour laquelle c'est une bonne stratégie lorsque vous sauvegardez déjà le serveur.

Quelques bonnes raisons sont apparues pour moi qui ne sont pas au-dessus. Que faire si votre application tierce ne parvient pas à effectuer une sauvegarde que vous pouvez restaurer? Avez-vous essayé de restaurer votre sauvegarde? Qu'en est-il d'un nouveau serveur que vous venez de construire à partir de vos modèles (pensez DR)? Qu'en est-il d'un autre serveur de votre domaine qui a un classement différent? ou instance SQL?

Je prends des sauvegardes redondantes sans raison autre que parfois votre application tierce n'est pas le moyen le plus rapide de restaurer. Parfois, le stockage dans lequel votre application tierce enregistre est également affecté ou corrompu pour ses propres raisons.