web-dev-qa-db-ja.com

（Ola Hallengren）前回のフルバックアップより古いログバックアップを削除しています

Ola Hallengrenのバックアップスクリプトをサーバーに展開するとき、ログバックアップの@CleanupTimeパラメータを常に0に設定します。このように、ログバックアップジョブが実行されるたびに、前回の完全バックアップより古いログバックアップファイルがチェックされ、それらが削除されます。ただし、これは完全なCOPY_ONLYバックアップにも当てはまります。ログバックアップジョブは、古いログバックアップファイルを削除するために、最後の非COPY_ONLYフルバックアップのみをチェックする必要があります。

これに遭遇したのは私だけなのか、それとも私が提案していることが理にかなっているのかと思っているだけです。 IDKがTESTデータベースを更新するために、正午に完全なコピーのみのバックアップを取る必要がある場合、そのコピーのみのバックアップは、通常の毎日のバックアップシーケンスに影響を与えません。あなたの考えを教えてください。

sql-serversql-server-2012backupmaintenanceola-hallengren
7
Guillermo Garcia

IIのパートII（私の答えを分割する必要がありました）

より良くする

ビジネスで定義されたRPOとRTOを考慮して、@CleanupTimeのパラメーターを0よりも大きい値に変更することができます。どうして？値0は、組み込みのフェイルセーフメカニズムでのみ機能しますtogether。

次のタイムラインを使用してみましょう。

  • 08:00バックアップログ
  • 09:00バックアップログ
  • 10:00バックアップログ
  • ...
  • 20:00バックアップデータベース
  • 21:00バックアップログ
  • ...

ある時点で、トランザクションログのバックアップ（およびフルバックアップ？）がネットワークドライブにコピーされ、バックアップソリューションによってそこからバックアップされます。ある種のテープやディスクストレージと組み合わせる場合もあります。最初のBACKUP LOG ...が最後のBACKUP DATABASE ...の後に発生するとすぐに、以前のBACKUP LOG ...ファイルがなくなります...

自問する質問

  • ネットワークバックアップが失敗した場合はどうなりますか？
  • この（テープ）バックアップはいつ行われますか？保証？
  • データベースの完全バックアップはいつ行われますか？
  • 何を復元したいですか？
  • どんなRTOがありますか？
  • あなたのビジネスにはどのRPOが必要ですか？

上記の質問を見て、別のクリーンアップ時間（@CleanupTime=48など）を使用して、データベースサーバーのディスクにトランザクションログのバックアップをさらに1時間保持することを検討してください。

利点

  • Olaのフェイルセーフメカニズムに依存しなくなった
  • COPY_ONLYバックアップを作成しても、データはまだディスク上にあります
  • ネットワークがダウンおよび... であっても、データはディスク上にあります。
    • ... BACKUP DATABASE ...を作成します
    • ... COPY_ONLYバックアップ

強固な基盤の構築

任意の時点で、何かが失敗します。将来のあらゆる失敗に対応できることを確認し、ソリューションが99、.....％フールプルーフになることを関係者に保証する必要があります。

どうやって

Olaのソリューションでの作業は非常に簡単です[〜＃〜] if [〜＃〜]データベースをどのように回復するか、およびビジネスのRPOとRTOに基づいて1つまたは2つのことを考えます。

私の個人的な実装は、次のスケジュール/保持ポリシーを持つことです：

生産システム

  • TLogのバックアップ
    • 時間単位@ xx：05（非SAPシステム）
    • Quarter Hourly @ xx：10、xx：25、xx：40、xx：55（SAPシステム）
    • 保持：48時間
  • 毎日の差分バックアップ
    • 月曜日-土曜日@ 20:00（非SAPシステム）
    • 月曜日-土曜日@ 22:00（SAPシステム）
    • 保持：168時間
  • 毎週の完全バックアップ
    • 日曜日20:00（非SAPシステム）
    • 日曜日@ 22:00（SAPシステム）
    • 保持：336時間

テストシステム

テストシステムは、稼働時間中にバックアップされます。これは、午前10:00または午後14:00の完全な場合と、トランザクションログバックアップの場合はxx：15になります。

なぜ私はこのようにするのですか

...またはこれらの決定の背後にある私の考え...

バックアップ時間を異なるスロットに分散することで、ストレージシステムのディスクI/Oを均等に分散しています。 1時間（FULL）または4時間ごと（TLOG）にディスクに大量のI/Oが集中することはありません。

データベースのサイズのため、SAPと非SAPを区別しています。

テストシステムは、日中にストレージをスラッシュすることができます。高いパフォーマンスへの影響はありません。

DIFFおよびFULLバックアップは、テープバックアップが開始する前に行われ、通常はテープバックアップが開始する前に終了します。

保持ポリシーにより、（テープ）バックアップソリューションが1日間停止した場合でも、ビジネスで定められたRTOおよびRPOに到達できます。

ネットワークが（全体的または部分的にのみ）ダウンしている場合でも、バックアップは引き続き機能し、RTOおよびRPOに準拠します。

あなたの思考プロセス

あなたの@CleanupTime設定は、おそらくOlaのスクリプトの誤った理解に基づいていました。

5
John aka hot2use

IIのパートI（私の答えを分割する必要がありました）

ここで1つまたは2つのことを考慮する必要があります。私の考えでは、思考プロセスの近道を取っているのかもしれません。この仮定をしている間に説明します...

あなたは私の受け入れられた回答を簡単に見たいかもしれません ここ 質問に関連して投稿された バックアップ戦略[提案]の提案が必要です についていくつかのアイデアを与えるRTOおよびRPO。

どうして？ @CleanupTime=0の設定は悪い考えかもしれないので...

最初にあなたの質問に答えてください。

それはオラのスクリプトのバグですか？-いいえオラは彼のデザインをしました最後のBACKUP DATABASE...（フルバックアップ）を確認してから、そのバックアップの前に発生したトランザクションログバックアップ（BACKUP LOG ...）のみを削除するスクリプト@CleanupTimeがフルバックアップの発生時よりも低い場合。

これはフェイルセーフメカニズムであり、一般的な機能として使用するためのものではありません。

BACKUP DATABASE ... WITH COPY_ONLY...はまだフルバックアップであるため、設計どおりに機能します。

安全第一

BACKUP DATABASE ... COPY_ONLY...オプションを使用してバックアップを作成し、次にBACKUP LOG...を作成すると、完全なCOPY_ONLYバックアップと使用可能なトランザクションログバックアップを使用して、データベースを一貫した状態に復元できます。

StackExchangeデータベースを使用してこれをテストしました。

  • COPY_ONLYバックアップを手動で作成する
  • 一部のデータを変更する
  • Olaのスクリプトを使用してBACKUP LOG ...を実行する
  • データベースの復元

COPY_ONLYを使用した手動バックアップ

 --------------------------------------------- ---- 
 BACKUP DATABASE [StackExchange] TO DISK = 'C：\ adhoc\StackExchange_Full_CopyOnly_20171221_082242.bak' 
 WITH COPY_ONLY、COMPRESSION、RETAINDAYS = 3、NOFORMAT、NOINIT、NAME = N'StackExchange -フルバックアップSichern '、SKIP、NOREWIND、
 NOUNLOAD、STATS = 10、CHECKSUM 
 ----------------------- -------------------------- 
 10パーセント処理されました。
 21パーセント処理されました。
 31処理率。
 40％処理済み。
 50％処理済み。
 61％処理済み。
 70％処理済み。
 80％処理済み。
 91パーセント処理されました。
データベース376ページを処理しました。ファイル1のファイル 'StackExchange'。
 100パーセント処理されました。
データベース 'StackExchangeの2ページを処理しました。 '、ファイル1のファイル' StackExchange_log '。
 BACKUP DATABASEは、378ページを0.027秒（109.103 MB /秒）で正常に処理しました。
 ------------------------------------------------- 
終了

Olaのスクリプトを使用したトランザクションログのバックアップ

日付21.12.2017 08:29:06 
ログジョブ履歴（OLA DatabaseBackup-USER_DATABASES-LOG）
 
ステップID 1 
サーバーMYNOTEBOOK 
ジョブ名OLA DatabaseBackup-USER_DATABASES-LOG 
ステップ名OLA DatabaseBackup-USER_DATABASES-LOG 
期間00:00:01 
 Sql重大度0 
 SQLメッセージID 0 
 Operator Emailed 
 Operator Net sent 
 Operator Paged 
 Retryries Attempted 0 
 
 Message 
ユーザーとして実行：NT Service\SQLSERVERAGENT。 ... 557.0 Edition：Developer Edition（64-bit）Procedure：[msdb]。[dbo]。[DatabaseBackup] Parameters：@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、@ Credential = NULL、@ MirrorDirectory = NULL、@ MirrorCleanupTime = NULL、@ MirrorCleanupMode = 'AFTER_BACKUP'、@ AvailabilityGroups = NULL、@ Updateability = 'ALL'、@ LogToTable = 'Y'、@ Execute = 'Y'ソース：https：// ola.hallengren.com日時：2017-12-21 08： 29:06データベース：[AdminDB2]ステータス：オンラインスタンバイ：いいえ更新可能性：READ_WRITEユーザーアクセス：MULTI_USERアクセス可能：はい復旧モデル：フル暗号化：いいえ差分ベースLSN：36000001056400037最後のログバックアップLSN：36000001061600001日時：2017-12 -21 08:29:06コマンド：DECLARE @ReturnCode int EXECUTE @ReturnCode = [master] .dbo.xp_create_subdir N'C：\ SQL\Backup\MYNOTEBOOK\AdminDB2\LOG 'IF @ReturnCode 0 RAISERROR（'ディレクトリ作成エラー。 '、16、1）結果：成功期間：00:00:00日時：2017-12-21 08:29:06日時：2017-12-21 08:29:06コマンド：
 
 [短縮] 
 
 ...プロセス終了コード0。ステップは成功しました。

戻す

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

タイムスタンプの違いはおよそではないかもしれません。 7分。

結果

 6％処理。
 10％処理。
 16％処理。
 21％処理。
 25％処理。
 31％処理。
 36％処理。
 40％処理。
 46％処理。
 50％処理。
 55％処理。
 61％処理。
 65％処理。
 70％処理。
 76％処理。
 80％処理。
 86処理率。
 91％処理済み。
 95％処理済み。
 100％処理済み。
処理済み376ページのデータベース「StackExchange」、ファイル「StackExchange」のファイル1。
データベース 'StackExchange'の2ページを処理し、ファイル 'StackExchange_log'をファイル1に処理しました。
 RESTORE DATABASEは、378ページを0.021秒（140.276 MB /秒）で正常に処理しました。
 100％処理されました。
データベース1でデータベース 'StackExchange'、ファイル 'StackExchange'で0ページが処理されました。
 dで2ページが処理されましたatabase 'StackExchange'、ファイル1のファイル 'StackExchange_log' 
 RESTORE LOGは2ページを0.005秒（2.441 MB /秒）で正常に処理しました。

概要

Olaのスクリプトは設計どおりに機能します。 BACKUP DATABASE ... WITH COPY_ONLY...と追加のBACKUP LOG ...が連動することを確認しました。フェイルセーフ機能により、最後の完全バックアップ（COPY_ONLYかどうかに関係なく）と使用可能なトランザクションログバックアップを使用してデータベースを復元できます。

（詳細については、IIのパートIIをお読みください）

3
John aka hot2use

あなたが正しいです！これはバグまたは仕様によるものだと思います。シナリオをレポできた。

したがって、基本的に、次のようにOlaのスクリプトを実行すると、

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

またはネイティブ：

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

新しい完全バックアップまたは完全copy_onlyバックアップ、さらには差分バックアップを実行すると、別のログバックアップ（@CleanupTime = 0パラメータを使用したOlaのログバックアップスクリプト）を実行すると、以前のログバックアップはすべて削除されます。

Olaのスクリプトバージョンを使用してテスト：2016年10月7日。

OlaのWebサイト に基づく：

CleanupTime

バックアップファイルが削除されるまでの時間を時間単位で指定します。時間を指定しない場合、バックアップファイルは削除されません。

DatabaseBackupには、最新の完全バックアップまたは差分バックアップよりも新しいトランザクションログバックアップが削除されていないことを確認するチェック機能があります。

COPY_ONLYバックアップについては触れられていません。

当面は、回避策としてログバックアップパラメータを@CleanupTime = NULLに変更してください。または、別のバックアップツール（例： Minion Backup または dbatools ）への移行を検討するか、またはOlaのメンテナンスプランは2016年10月7日でした。問題/機能強化を提起したい場合は、 github があります。

1
user37701