Sauvegardes de transaction SQL Server vs journaux

J'ai hérité d'une base de données SQL Server 2008 critique de taille modérée et j'essaie de comprendre la planification de la sauvegarde. (Je suis développeur, pas DBA.)

La façon dont notre système est configuré actuellement, il existe deux systèmes de sauvegarde:

1. Sauvegardes hebdomadaires complètes ( .bak) et sauvegardes horaires du journal des transactions ( .trn). Nous conservons plusieurs ensembles de ces sauvegardes et elles sont régulièrement expédiées hors site.
2. Journaux SQL Server ( .ldf), avec le modèle de récupération défini sur Full. Ce fichier se trouve sur un lecteur distinct du .mdffichier principal , mais n'est pas autrement sauvegardé.

En cas de restauration d'urgence (ou lors de la restauration de sauvegardes sur une machine de développement), ma procédure consiste à utiliser les .bakfichiers puis à appliquer les fichiers .trn. Nous avons un script qui rend cette procédure relativement simple.

Mes questions:

1. Est-il possible de restaurer la base de données à partir du .ldffichier? À quoi ça sert même?
2. Est-il inutilement redondant d'avoir ces deux journaux de transactions?
3. Est-il important de sauvegarder le .ldffichier?

Non, il n'est pas possible de restaurer une base de données à partir d'un fichier ldf. Le fichier ldf serait restauré avec les fichiers mdf.

Non, ce n'est pas redondant car ils ont deux objectifs différents.

Il est important d'effectuer des sauvegardes complètes et des sauvegardes du journal des transactions. La possession d'une copie du fichier ldf ne vous aide pas à restaurer la base de données.

Quant à savoir à quoi sert un fichier ldf, le ldf est le journal des transactions. Considérez-le comme un tampon circulaire qui enregistre les modifications apportées à votre base de données. Lorsque vous mettez à jour une ligne, la modification est immédiatement écrite dans le ldf. À un certain moment dans le futur (généralement moins de cinq minutes), les données modifiées sont écrites dans le fichier mdf.

Si le serveur tombe en panne ou s'il y a une panne de courant, lorsque SQL démarre, il lit le ldf et réapplique (REDO) ces modifications.

En outre, si vous avez une transaction qui n'a pas été validée et que le serveur se bloque, toutes les modifications apportées par cette transaction doivent être annulées pour rendre la base de données cohérente. Le fichier ldf a également cette tâche. (ANNULER)

J'ai mentionné ci-dessus que le fichier ldf est circulaire. Une sauvegarde du journal des transactions (.trn) copie une partie du fichier ldf. Après avoir créé un fichier trn en toute sécurité, sql peut réutiliser cette partie du fichier ldf. La série de sauvegardes trn crée une chaîne qui enregistre ensemble toutes les modifications apportées à la base de données. Bien sûr, si vous n'avez jamais effectué de sauvegarde du journal des transactions, le fichier ldf grandirait et grandirait et grandirait.

Dans un scénario de catastrophe, la restauration de la sauvegarde complète vous permet d'obtenir une copie de la base de données au moment où la sauvegarde complète est terminée. Vous pouvez ensuite restaurer les fichiers trn dans l'ordre et mettre la base de données à jour à tout moment, y compris jusqu'à la dernière sauvegarde trn.

Je passe sous silence certains détails importants, mais l'essentiel est que ldf est un fichier de travail qui enregistre les modifications récentes de la base de données. Les fichiers trn sont des copies de parties du ldf faites en supposant que vous les conserverez ensuite en sécurité afin que sql puisse réutiliser l'espace dans le ldf et si une catastrophe survient, vous les aurez dans un autre emplacement.