(Ola Hallengren) Suppression des sauvegardes de journaux antérieures à la dernière sauvegarde COMPLÈTE
Lorsque je déploie le script de sauvegarde d'Ola Hallengren sur mes serveurs, je remets toujours le paramètre @CleanupTime pour les sauvegardes de journaux à zéro. De cette façon, chaque fois que le travail de sauvegarde du journal s'exécute, il recherche les fichiers de sauvegarde du journal antérieurs à la dernière sauvegarde complète et les supprime. Cependant, cela est également vrai pour les sauvegardes complètes de COPY_ONLY! Le travail de sauvegarde du journal ne doit vérifier que la dernière sauvegarde complète non_COPY_ONLY afin de supprimer les anciens fichiers de sauvegarde du journal.
Je me demande simplement si je suis le seul à avoir rencontré cela, ou si ce que je propose est logique. Si je dois effectuer une sauvegarde de copie complète uniquement en milieu de journée pour actualiser IDK une base de données TEST, cette sauvegarde de copie uniquement ne devrait pas affecter la séquence de sauvegarde quotidienne régulière. Faites-moi savoir vos pensées, s'il vous plaît.
Partie II de II (a dû diviser ma réponse)
Faire mieux
Compte tenu de votre RPO et RTO définis par votre entreprise, vous souhaiterez peut-être maintenant modifier le paramètre de @CleanupTime à quelque chose de plus élevé que 0. Pourquoi? Parce que la valeur 0 ne fonctionnera que ensemble avec le mécanisme de sécurité intégré.
Utilisons la chronologie suivante:
- 08:00 JOURNAL DE SAUVEGARDE
- 09:00 JOURNAL DE SAUVEGARDE
- 10:00 JOURNAL DE SAUVEGARDE
- ...
- 20:00 BASE DE DONNÉES DE SAUVEGARDE
- 21:00 JOURNAL DE SAUVEGARDE
- ...
À un moment donné, vos sauvegardes du journal des transactions (et les sauvegardes complètes?) Sont copiées sur un lecteur réseau et sauvegardées à partir de là au moyen d'une solution de sauvegarde, éventuellement combinée avec une sorte de stockage sur bande et/ou sur disque. Dès le premier BACKUP LOG ... se produit après le dernier BACKUP DATABASE ... votre précédent BACKUP LOG ... les fichiers ont disparu ...
Questions à se poser
- Que se passe-t-il si votre sauvegarde réseau échoue?
- Quand cette sauvegarde (sur bande) a-t-elle lieu? Garanti?
- Quand la sauvegarde complète de la base de données a-t-elle lieu?
- Que voulez-vous pouvoir restaurer?
- Quel RTO avez-vous?
- De quel RPO votre entreprise a-t-elle besoin?
En examinant les questions ci-dessus, envisagez d'utiliser une heure de nettoyage différente (par exemple @CleanupTime=48) pour conserver des heures supplémentaires de sauvegardes du journal des transactions sur les disques de votre serveur de base de données.
Avantages
- Vous ne comptez plus sur le mécanisme de sécurité intégrée d'Ola
- Vos données sont toujours sur le disque, même si vous créez un
COPY_ONLYsauvegarde - Vos données sont toujours sur le disque, même si le réseau tombe en panne et ...
- ... vous créez un
BACKUP DATABASE ... - ... une
COPY_ONLYsauvegarde
- ... vous créez un
Bâtir une base solide
À un moment donné, quelque chose échouera. Vous devez vous assurer que vous pouvez répondre à toutes les pannes en cours de route et garantir aux parties prenantes que votre solution sera à 99, .....% infaillible.
Comment je le fais
Travailler avec la solution d'Ola est un jeu d'enfant absolu, SI vous faites une ou deux réflexions sur la façon dont vous souhaitez récupérer une base de données et en fonction de votre RPO et RTO de votre entreprise.
Mon implémentation personnelle consiste à avoir les horaires/politiques de rétention suivants:
Systèmes de production
- TLog de sauvegarde
- Toutes les heures @ xx: 05 (systèmes non SAP)
- Trimestrielle @ xx: 10, xx: 25, xx: 40, xx: 55 (systèmes SAP)
- Rétention: 48 heures
- Sauvegarde différentielle quotidienne
- Lundi - samedi @ 20:00 (systèmes non SAP)
- Lundi - samedi @ 22:00 (systèmes SAP)
- Rétention: 168 heures
- Sauvegarde complète hebdomadaire
- Dimanche à 20h00 (systèmes non SAP)
- Dimanche à 22h00 (systèmes SAP)
- Rétention: 336 heures
Systèmes de test
Le système de test sera sauvegardé pendant les heures de production. Cela peut être 10h00 du matin ou 14h00 l'après-midi pour les sauvegardes complètes et xx: 15 pour les sauvegardes du journal des transactions.
Pourquoi je fais comme ça
... ou mes pensées derrière ces décisions ...
En répartissant les temps de sauvegarde sur différents emplacements, je distribue uniformément les E/S disque sur les systèmes de stockage. Aucun regroupement d'E/S massives sur le disque aux heures pleines (FULL) ou trimestrielles (TLOG).
Je fais la différence entre SAP et non-SAP en raison de la taille des bases de données.
Les systèmes de test sont autorisés à détruire le stockage pendant la journée. Aucun impact sur les hautes performances.
Les sauvegardes DIFF et FULL se produisent avant le démarrage des sauvegardes sur bande et sont normalement terminées avant le démarrage des sauvegardes sur bande.
Les politiques de rétention me permettent d'atteindre le RTO et le RPO définis par l'entreprise même si la solution de sauvegarde (sur bande) est en panne pendant une journée.
Les sauvegardes continueront de fonctionner et seront conformes à RTO et RPO même si le réseau (dans son ensemble ou seulement partiellement) est en panne pendant une journée.
Votre processus de réflexion
Votre @CleanupTime le paramètre était probablement basé sur une mauvaise compréhension du script d'Ola.
Partie I de II (a dû diviser ma réponse)
Il y a une ou deux choses à penser ici. À mon avis, vous avez peut-être pris un raccourci dans le processus de réflexion. Je vais expliquer pendant que je fais cette hypothèse ...
Vous voudrez peut-être jeter un coup d'œil à ma réponse acceptée ici qui a été publiée en référence à la question Besoin d'une suggestion sur la stratégie de sauvegarde [fermée] pour vous donner quelques idées sur RTO et RPO.
Pourquoi? Parce que la configuration de @CleanupTime=0 pourrait être une mauvaise idée ...
Répondez d'abord à votre question.
Est-ce un bug dans le script d'Ola? - Non. Ola a conçu son script pour vérifier le dernier BACKUP DATABASE... (Sauvegarde complète) puis pour supprimer les sauvegardes des journaux de transactions (BACKUP LOG ...) survenus avant cette sauvegarde et uniquement si le @CleanupTime est inférieur à celui de la sauvegarde complète.
Il s'agit d'un mécanisme de sécurité intégrée et non destiné à être utilisé comme une caractéristique générale.
Fonctionne comme prévu, car un BACKUP DATABASE ... WITH COPY_ONLY... est toujours une sauvegarde complète .
La sécurité d'abord
Création d'une sauvegarde avec le BACKUP DATABASE ... COPY_ONLY... option, puis en créant BACKUP LOG... vous permettra toujours de restaurer la base de données dans un état cohérent à l'aide de FULL COPY_ONLY sauvegarde et les sauvegardes du journal des transactions disponibles.
J'ai testé cela en utilisant ma base de données StackExchange:
- Créer un
COPY_ONLYsauvegarde manuelle - Modification de certaines données
- Exécution d'un
BACKUP LOG ...en utilisant les scripts d'Ola - Restauration de la base de données
Sauvegarde manuelle avec COPY_ONLY
--------------------------------------------- ---- BASE DE DONNÉES DE SAUVEGARDE [StackExchange] SUR DISQUE = 'C:\adhoc\StackExchange_Full_CopyOnly_20171221_082242.bak' AVEC COPY_ONLY, COMPRESSION, RETAINDAYS = 3, NOFORMAT, NOINIT, NAME = N'StackExc -Full Backup Sichern ', SKIP, NOREWIND, NOUNLOAD, STATS = 10, CHECKSUM ----------------------- -------------------------- 10% traités. 21% traités. 31 pour cent traité. 40 pour cent traité. 50 pour cent traité. 61 pour cent traité. 70 pour cent traité. 80 pour cent traité. 91 pour cent traités. Traités 376 pages pour la base de données 'StackExchange', fichier 'StackExchange' dans le fichier 1. 100 pour cent traités. Traités 2 pages pour la base de données 'StackExchange ', fichier' StackExchange_log 'dans le fichier 1. LA BASE DE DONNÉES DE SAUVEGARDE a réussi à traiter 378 pages en 0,027 seconde (109,103 Mo/sec). ------------------------------------------------- Fini
Sauvegarde du journal des transactions avec les scripts d'Ola
Date 21.12.2017 08:29:06
Historique des travaux de journal (OLA DatabaseBackup - USER_DATABASES - LOG)
Étape ID 1
Serveur MYNOTEBOOK
Nom du travail OLA DatabaseBackup - USER_DATABASES - LOG
Étape Nom OLA DatabaseBackup - USER_DATABASES - LOG
Durée 00:00:01
Sql Severity 0
ID de message SQL 0
Opérateur envoyé par courrier électronique
Opérateur Net envoyé
Opérateur paginé
Tentatives tentées 0
Message
Exécuté en tant qu'utilisateur: NT Service\SQLSERVERAGENT. ... 557.0 Edition: Developer Edition (64 bits) Procédure: [msdb]. [Dbo]. [DatabaseBackup] Paramètres: @Databases = 'USER_DATABASES', @Directory = 'C:\SQL\Backup', @BackupType = 'LOG', @Verify = 'Y', @CleanupTime = 48, @CleanupMode = 'AFTER_BACKUP', @Compress = NULL, @CopyOnly = 'N', @ChangeBackupType = 'N', @BackupSoftware = NULL, @CheckSum = 'Y', @BlockSize = NULL, @BufferCount = NULL, @MaxTransferSize = NULL, @NumberOfFiles = NULL, @CompressionLevel = NULL, @Description = NULL, @Threads = NULL, @Throttle = NULL, @Encrypt = 'N' , @EncryptionAlgorithm = NULL, @ServerCertificate = NULL, @ServerAsymmetricKey = NULL, @EncryptionKey = NULL, @ReadWriteFileGroups = 'N', @OverrideBackupPreference = 'N', @NoRecovery = 'N', @URL = NULL, @ NULL, @MirrorDirectory = NULL, @MirrorCleanupTime = NULL, @MirrorCleanupMode = 'AFTER_BACKUP', @AvailableGroups = NULL, @Updateability = 'ALL', @LogToTable = 'Y', @Execute = 'Y' Source: https: // ola.hallengren.com Date et heure: 21/12/2017 08: 29:06 Base de données: [AdminDB2] Statut: EN LIGNE Veille: Non Mise à jour: READ_WRITE Accès utilisateur: MULTI_USER Est accessible: Oui Modèle de récupération: COMPLET Chiffré: Non Base différentielle LSN: 36000001056400037 Dernière sauvegarde du journal LSN: 36000001061600001 Date et heure: 2017-12 -21 08:29:06 Commande: DECLARE @ReturnCode int EXECUTE @ReturnCode = [master] .dbo.xp_create_subdir N'C:\SQL\Backup\MYNOTEBOOK\AdminDB2\LOG 'IF @ReturnCode 0 RAISERROR (' Erreur lors de la création du répertoire. ', 16, 1) Résultat: Réussi Durée: 00:00:00 Date et heure: 2017-12-21 08:29:06 Date et heure: 2017-12-21 08:29:06 Commande:
[raccourci]
... Code de sortie de processus 0. L'étape a réussi.
Restaurer
USE [master]
-- Restore the COPY_ONLY Backup
RESTORE DATABASE [StackExchange] FROM DISK = N'C:\adhoc\StackExchange_Full_CopyOnly_20171221_082242.bak'
WITH REPLACE, FILE = 1, NORECOVERY, NOUNLOAD, STATS = 5
-- Restore an OLA Transaction Log backup
RESTORE LOG [StackExchange] FROM DISK = N'C:\SQL\Backup\MYNOTEBOOK\StackExchange\LOG\NB31710_StackExchange_LOG_20171221_082906.trn'
WITH FILE = 1, NOUNLOAD, STATS = 5
Vous ne pouvez pas la différence dans les horodatages est d'env. 7 minutes.
Résultats
6% traités. 10% traités. 16% traités. 21% traités. 25% traités. 31% traités. 36% traités. 40% traités. 46% traités. 50% traités. 55% traités. 61% traités. 65% traités. 70% traités. 76% traités. 80% traités. 86 pour cent traité. 91 pour cent traité. 95 pour cent traité. 100 pour cent traité. 376 pages traitées pour la base de données 'StackExchange', fichier 'StackExchange' dans le fichier 1. 2 pages traitées pour la base de données 'StackExchange', fichier 'StackExchange_log' dans le fichier 1. RESTORE DATABASE a réussi à traiter 378 pages en 0,021 seconde (140,276 Mo/sec). 100% traité. 0 pages traitées pour la base de données 'StackExchange', fichier 'StackExchange' sur le fichier 1. 2 pages traitées pour d atabase 'StackExchange', fichier 'StackExchange_log' sur le fichier 1. RESTORE LOG a traité avec succès 2 pages en 0,005 secondes (2,441 Mo/sec).
Sommaire
Le script d'Ola fonctionne comme prévu. Nous avons vérifié qu'un BACKUP DATABASE ... WITH COPY_ONLY... et un autre BACKUP LOG ... fonctionnera ensemble. La fonction de sécurité intégrée garantit que vous pouvez restaurer votre base de données avec la dernière sauvegarde complète (que ce soit COPY_ONLY ou non) et les sauvegardes du journal des transactions disponibles.
(Veuillez lire la partie II de II pour plus de réponses)
Tu as raison! Je pense que c'est un bug ou un by-design. J'ai pu repo le scénario.
Donc, fondamentalement, lorsque vous exécutez le script d'Ola avec ceci:
EXECUTE [master].[dbo].[DatabaseBackup]
@Databases = 'UserShrinkSizeTest',
@Directory = N'C:\Backup',
@BackupType = 'FULL',
@Verify = 'Y',
@CleanupTime = NULL,
@CheckSum = 'Y',
@LogToTable = 'Y',
@CopyOnly = 'Y' --copy_only param
Ou natif:
-- native copy_only
BACKUP DATABASE [UserShrinkSizeTest]
TO DISK = N'C:\Backup\machine$SQLSERVER16\UserShrinkSizeTest\COPY_ONLY\UserShrinkSizeTest_21122017_COPYONLY.bak'
WITH COPY_ONLY, INIT, STATS = 1
GO
Lorsque vous exécutez une nouvelle sauvegarde complète ou une sauvegarde complète copy_only Ou même une sauvegarde différentielle, toutes vos sauvegardes de journal précédentes seront supprimées après avoir exécuté une autre sauvegarde de journal (script de sauvegarde de journal d'Ola avec le paramètre @CleanupTime = 0).
Testé à l'aide de la version de script d'Ola: 7 octobre 2016 .
Basé sur site Web d'Ola :
CleanupTime
Spécifiez la durée, en heures, après laquelle les fichiers de sauvegarde sont supprimés. Si aucune heure n'est spécifiée, aucun fichier de sauvegarde n'est supprimé.
DatabaseBackup a une vérification pour vérifier que les sauvegardes du journal des transactions qui sont plus récentes que la sauvegarde complète ou différentielle la plus récente ne sont pas supprimées.
Il ne mentionne pas les sauvegardes COPY_ONLY.
Pour l'instant, vous pouvez remplacer le paramètre de sauvegarde du journal par @CleanupTime = NULL Comme solution de contournement. Ou envisagez de passer à un autre outil de sauvegarde (par exemple Sauvegarde Minion ou dbatools ) ou lancez votre propre code personnalisé car la dernière mise à jour du plan de maintenance d'Ola a eu lieu le 7 octobre 2016. Il y a un github si vous souhaitez soulever un problème/une amélioration.