web-dev-qa-db-fra.com

Comprendre CleanupTime dans les scripts SQL Server d'Ola Hallengren en relation avec les sauvegardes complètes et les sauvegardes LOG

J'ai du mal à comprendre à quoi s'attendre exactement de l'option CleanupTime dans Ola Hallengren Server Maintenance Solution . Je trouve des questions connexes et des réponses élaborées, mais les explications me laissent encore un peu perplexe.

Plus précisément:

Je fais une sauvegarde FULL hebdomadaire, une sauvegarde DIFF quotidienne et une sauvegarde LOG journalière. La sauvegarde COMPLÈTE utilise le CleanupTime par défaut de 24h. Les sauvegardes DIFF et LOG ont NULL comme CleanupTime.

À partir de documentation du paramètre CleanupTime , je n'arrive pas à comprendre si la définition du paramètre CleanupTime pour une sauvegarde de BackupType FULL, supprimera également les anciens fichiers de sauvegarde DIFF et LOG , ou uniquement Fichiers de sauvegarde COMPLETS.

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é.

Ce dernier paragraphe me fait penser que la définition de CleanupTime sur les sauvegardes de BackupType FULL supprimera également les journaux de transactions plus anciens. Pourtant, il n'est pas clair si ce paragraphe s'applique uniquement aux sauvegardes du BackupType LOG, ou également aux sauvegardes du BackupType FULL.

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.

Ce que j'essaie de réaliser, c'est que je peux faire une récupération ponctuelle jusqu'à 1 semaine. (Nous avons une base de données qui évolue très lentement, donc c'est faisable) D'après ce que je comprends maintenant, cela nécessiterait une sauvegarde complète d'une semaine et une semaine de sauvegarde du journal des transactions. Étant donné que les sauvegardes complètes et différentielles ne peuvent être utilisées que pour restaurer à un moment précis.

Donc, dois-je simplement définir l'option CleanupTime de mon travail de sauvegarde COMPLÈTE sur 24*7? Ce que je suppose maintenant, c'est que si vous le définissez sur 24h, la prochaine sauvegarde complète supprimera tous les fichiers de sauvegarde de journal de transactions complets, diff et , me laissant avec une fenêtre de récupération ponctuelle de ... 0 heures. Droite?

sql-serverbackupsql-server-2016ola-hallengren
7
Wouter

Le @CleanupTime Est toujours spécifié pour un travail de sauvegarde spécifique. Par exemple, si vous créez un travail de sauvegarde Complet, un travail de sauvegarde Différentiel et un travail de sauvegarde Journal des transactions, alors le @CleanupTime concerne toujours la prolongation de l'emploi.

Jetons un coup d'œil à un exemple de sauvegarde Full.

Sauvegarde complète

Si vous créez un travail de sauvegarde complète, vous ajouterez normalement un ou plusieurs des paramètres suivants:

  • @Databases: Quelles bases de données sont sauvegardées (pas vraiment pertinentes pour cet exemple)
  • @Directory: Le répertoire pour stocker les sauvegardes
  • @BackupType: Complet, Différentiel, TLog
  • @CleanupTime: Combien d'heures de sauvegardes conserver
  • @FileExtensionFull: L'extension de votre sauvegarde.

Vous avez donc un travail de sauvegarde en place qui créera une sauvegarde complète selon le calendrier que vous avez défini pour le travail. Supposons ce qui suit:

  • ce travail s'exécute à 20h00 (20h00)
  • @FileExtensionFull A été défini sur 'BAK'
  • @Directory A été défini sur 'F:\SQLBACKUP'
  • @CleanupTime A été défini sur 24 (Heures)

Si nous regardons le fichier MaintenanceSolution.sql, Vous trouverez la description du paramètre:

SET @CleanupTime         = NULL         
-- Time in hours, after which backup files are deleted. If no time is specified, then no backup files are deleted.

Eh bien, cela n'aide pas beaucoup. Identique à la documentation officielle sur le site. Allons plus loin. Si vous parcourez le script, vous finirez par trouver une section qui ressemble à ceci:

Le script a été encapsulé pour augmenter la lisibilité 

 SI @BackupSoftware IS NULL 
 COMMENCER 
 SET @ CurrentCommandType02 = 'xp_delete_file' 
 SET @ CurrentCommand02 = 
 'DECLARE @ReturnCode int 
 EXECUTE @ReturnCode = [master] .dbo.xp_delete_file 0, 
 N' '' + REPLACE (@CurrentDirectoryPath, '' '', '' '' '' ) + '' ', - premier paramètre 
' '' + @CurrentFileExtension + '' ', --second paramètre 
' '' + CONVERT (nvarchar (19), @ CurrentCleanupDate, 126 ) + '' '- troisième paramètre 
 IF @ReturnCode 0 RAISERROR (' 'Erreur lors de la suppression des fichiers.' ', 16, 1)' 
 END

Ola utilise donc essentiellement le xp_delete_file function Intégré de SQL Server pour supprimer un fichier à un certain moment en fonction de:

  • @CurrentDirectoryPath
  • @CurrentFileExtension
  • @CurrentCleanupDate

Mais attendez ce que serait par exemple le @CurrentCleanupDate? Si nous remontons un peu dans le script, vous pouvez trouver une section qui ressemble à ceci:

 INSÉRER DANS @CurrentCleanupDates (CleanupDate, Mirror) 
 SELECT DATEADD (hh, @ CleanupTime), GETDATE ()), 0

Ah, donc le @CurrentCleanupDate Est une addition de date qui est calculée à partir du @CleanupTime Et de l'heure actuelle GETDATE(). Cool.
(... et nous venons peut-être de trouver une faute de frappe dans le code, car les sections pour les bases de données normale et miroir contiennent toutes deux --- (Mirror dans le code.)

Quelle est alors la section pertinente pour @CurrentFileExtension? Cherchons encore un peu. Et nous trouvons:

 SELECT @CurrentFileExtension = CASE 
 WHEN @CurrentBackupType = 'FULL' THEN @FileExtensionFull 
 WHEN @CurrentBackupType = 'DIFF' THEN @FileExtensionDiff 
 WHEN @CurrentBackupType = '. LOG 'THEN @FileExtensionLog 
 END

Alors voilà.

Sommaire

Si les paramètres de votre tâche de sauvegarde Complète sont définis comme @FileExtensionFull='BAK' Et que vous avez défini un @CleanupTime=24, La procédure supprimera tout Complète sauvegarde fichiers datant d'au moins un jour (24 heures).

Le @CurrentCommand02 Qui est exécuté est essentiellement:

xp_delete_file 0, 'F:\SQLBACKUP', 'BAK', '2018-08-20 20:00:00.045'

Il ne touche donc à aucun autre fichier de sauvegarde. (À moins bien sûr que vous ayez défini 'BAK' Comme étant l'extension de tous les types de sauvegarde, auquel cas vous perdez).

18
John aka hot2use

J'ai surévalué la réponse de @ hot2use car elle couvre cette question en détail, mais je voulais partager un moyen facile de tester ce genre de choses.

Cela pourrait vous aider (comme cela m'a aidé) à comprendre pleinement le fonctionnement du script si vous:

  1. Installez le script de sauvegarde (et d'autres dépendances) sur une instance de test - j'ai testé sur mon ordinateur local.
  2. Maintenant, modifiez le script et recherchez/remplacez hh par minute. Les seules références que je peux trouver avec hh sont où le script traite le temps de nettoyage. Cela vous permet d'exécuter rapidement des sauvegardes de différents types (FULL, DIFF, LOG) voir les effets de l'exécution car la rétention est en minutes et non en heures.

Exécutez une sauvegarde FULL, DIFF et LOG d'une base de données de test et notez les fichiers créés dans les dossiers individuels. Voici ce que j'ai utilisé (notez le CleanupTime de 1 minute en raison de la modification du script d'heures en minutes):

exec [dbo].[DatabaseBackup]
@Databases = 'test',
@Directory = 'C:\OlaBackupTest',
@BackupType = 'full',
@Verify = 'N',
@CleanupTime = 1,
@CleanupMode = 'AFTER_BACKUP'

exec [dbo].[DatabaseBackup]
@Databases = 'test',
@Directory = 'C:\OlaBackupTest',
@BackupType = 'diff',
@Verify = 'N',
@CleanupTime = 1,
@CleanupMode = 'AFTER_BACKUP'

exec [dbo].[DatabaseBackup]
@Databases = 'test',
@Directory = 'C:\OlaBackupTest',
@BackupType = 'log',
@Verify = 'N',
@CleanupTime = 1,
@CleanupMode = 'AFTER_BACKUP'

Mes tests ont révélé les observations suivantes:

COMPLET

Chaque exécution d'une sauvegarde FULL créait une nouvelle sauvegarde FULL et supprimait tous les fichiers de sauvegarde FULL de plus d'une minute. Aucun fichier de sauvegarde DIFF ou LOG n'a été affecté.

DIFF

Chaque exécution d'une sauvegarde DIFF créait une nouvelle sauvegarde DIFF et supprimait tous les fichiers de sauvegarde DIFF de plus d'une minute. Aucun fichier de sauvegarde FULL ou LOG n'a été affecté.

JOURNAL

Chaque exécution d'une sauvegarde LOG créait une nouvelle sauvegarde LOG. Les sauvegardes LOG continues (sans intervenir FULL ou DIFF sauvegardes) ont simplement continué à s'accumuler dans le dossier de sauvegarde LOG sans tenir compte du temps de nettoyage. Si une sauvegarde FULL ou DIFF a finalement été effectuée, la PROCHAINE exécution de la sauvegarde LOG a supprimé toutes les sauvegardes LOG plus anciennes que la dernière FULL ou DIFF et également plus d'une minute.

Aucun fichier de sauvegarde FULL ou DIFF n'a été affecté lors de l'exécution des sauvegardes LOG.

Je recommanderais de conserver plus d'une semaine de sauvegardes FULL au cas où vous auriez besoin de remonter le temps pour restaurer. En supposant 2 semaines de FULL sauvegardes, vous auriez besoin d'un CleanupTime de 336 heures.

Au cours de votre test du truc d'une minute, vous verrez que:

  • L'exécution de sauvegardes FULL ne supprime jamais les sauvegardes DIFF ou LOG
  • L'exécution de sauvegardes DIFF ne supprime jamais les sauvegardes FULL ou LOG
  • L'exécution de sauvegardes LOG ne supprime jamais les sauvegardes FULL ou DIFF
8
Scott Hodgin

Développant les deux autres réponses, car je viens de rencontrer ceci:

Peut être intéressant de noter (à qui peut google cela). pour permettre un peu plus que l'heure exacte à laquelle vous souhaitez conserver votre sauvegarde.

Si op veut conserver la sauvegarde de 1 semaine, les 24x7 heures ne garderont pas toujours le fichier de 1 semaine. Raison: les bases de données se développent. Votre nouvelle sauvegarde peut prendre un peu plus de temps.

Si votre premier fichier de sauvegarde a été créé 2020-03-15 03: 00: 05.000 Et la sauvegarde suivante prend un peu plus de temps et le fichier est créé 2020-03-22 30: 00: 0 6. 000 - c'est plus que les 168 heures spécifiées (une seconde, attention)

Donc pour être sûr, faites-le 24x7 + 1!

0
Daniel