Ola Hallengrenのバックアップスクリプトをサーバーに展開するとき、ログバックアップの@CleanupTime
パラメータを常に0に設定します。このように、ログバックアップジョブが実行されるたびに、前回の完全バックアップより古いログバックアップファイルがチェックされ、それらが削除されます。ただし、これは完全なCOPY_ONLY
バックアップにも当てはまります。ログバックアップジョブは、古いログバックアップファイルを削除するために、最後の非COPY_ONLY
フルバックアップのみをチェックする必要があります。
これに遭遇したのは私だけなのか、それとも私が提案していることが理にかなっているのかと思っているだけです。 IDKがTESTデータベースを更新するために、正午に完全なコピーのみのバックアップを取る必要がある場合、そのコピーのみのバックアップは、通常の毎日のバックアップシーケンスに影響を与えません。あなたの考えを教えてください。
IIのパートII(私の答えを分割する必要がありました)
ビジネスで定義されたRPOとRTOを考慮して、@CleanupTime
のパラメーターを0
よりも大きい値に変更することができます。どうして?値0
は、組み込みのフェイルセーフメカニズムでのみ機能しますtogether。
次のタイムラインを使用してみましょう。
ある時点で、トランザクションログのバックアップ(およびフルバックアップ?)がネットワークドライブにコピーされ、バックアップソリューションによってそこからバックアップされます。ある種のテープやディスクストレージと組み合わせる場合もあります。最初のBACKUP LOG ...
が最後のBACKUP DATABASE ...
の後に発生するとすぐに、以前のBACKUP LOG ...
ファイルがなくなります...
上記の質問を見て、別のクリーンアップ時間(@CleanupTime=48
など)を使用して、データベースサーバーのディスクにトランザクションログのバックアップをさらに1時間保持することを検討してください。
COPY_ONLY
バックアップを作成しても、データはまだディスク上にありますBACKUP DATABASE ...
を作成しますCOPY_ONLY
バックアップ任意の時点で、何かが失敗します。将来のあらゆる失敗に対応できることを確認し、ソリューションが99、.....%フールプルーフになることを関係者に保証する必要があります。
Olaのソリューションでの作業は非常に簡単です[〜#〜] if [〜#〜]データベースをどのように回復するか、およびビジネスのRPOとRTOに基づいて1つまたは2つのことを考えます。
私の個人的な実装は、次のスケジュール/保持ポリシーを持つことです:
テストシステムは、稼働時間中にバックアップされます。これは、午前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のスクリプトの誤った理解に基づいていました。
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
バックアップを手動で作成する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 /秒)で正常に処理しました。 ------------------------------------------------- 終了
日付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をお読みください)
あなたが正しいです!これはバグまたは仕様によるものだと思います。シナリオをレポできた。
したがって、基本的に、次のように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 があります。