ローカルバックアップとは異なるバックアッププランを使用したAzureBlobへのSQLServerバックアップ
いくつかの重要な基盤を備えた本番SQLServerがあります。現時点では、以下を実行する保守計画があります。
- 毎週土曜日に4週間のTTL）で完全バックアップを作成します
- 2週間のTTL）で毎晩（土曜日を除く）DIFFバックアップを作成します
- TTL 1週間）で1時間ごとにLOGバックアップを作成します
そのため、過去4週間の土曜日、過去2週間の任意の日（夜）、および過去1週間のほぼすべての特定の時点にデータベースを復元できます。また、 Ola Hallengren によるバックアップスクリプトを使用しており、データベースはSharePointとTFS用です。
4週間はそれほど長くはなく、それらのバックアップは最終的にはローカルバックアップであると認識しているため、それらが稼働している物理サーバーに重大な問題が発生した場合、問題が発生します。
Azure Blobsを使用してオンラインバックアップを保存したかったのですが（LOGはローカルのままであるため、FULLとDIFFの場合）、その方法について適切な計画を立てるのに少し問題があります。主な問題は、インターネット接続があまり高速ではなく（オフィスには対称的な30/30しかない）、Azureにはお金がかかることです（Blobは安価ですが、それでも）。しかし、間違いなく、ネットワーク速度が主要な問題です。
Azureでローカルバックアップとは異なるバックアッププランを使用したかったのですが、すぐに問題が発生しました。両方のバックアップ場所で完全バックアップが同じでなく、同じ完全バックアップを作成できない場合、DIFFバックアップは役に立たなくなります。 Blobsのスケジュールを変えたい場合は、両方の場所。
これをより実用的な例にすると、毎月最初の週末に完全バックアップをAzureに保存したいとします...ローカルバックアップが同じであれば、それは問題にはなりません。しかし、今、Azureにコピーのみの完全バックアップを実行すると、Azureに保存されている毎日のDIFFバックアップが機能しなくなります。 Azureへのコピーのみではない完全バックアップを実行すると、ローカルバックアップが壊れます。さらに、最初のAzureバックアップの後の最初の完全ローカルバックアップは、とにかくAzure上の後続のDIFFバックアップを中断します。
私ができる唯一のことは、完全バックアップの頻度を減らし（たとえば、月に1 FULL？）、それに応じてTTL）を増やし、Azureの同じバックアップ計画を立てることです（スクリプト内のMIRRORオプション）。ただし、これでは完全バックアップには不十分な場合が多いのではないかと心配しています。あるいは、OlaによるスクリプトにはModificationLevelパラメーターがありますが、その方法がわかりません。最適なストレージスペース使用率のためにそれを使用してください。
または、（SQL-backup-to-Azureソリューションではなく）file-sync-to-Azureソリューションを利用することもできますが、これは実際には同じ問題です。
ローカルSQLバックアップとは異なるAzureのバックアップ計画を立てる方法はありますか？
@LowlyDBAが指摘したように、「ファイルをAzure BLOBにアップロードするための別のジョブを持つ」ことは、ここでの正しいアプローチです。差分バックアップまたはログバックアップを管理する2つの別々のジョブを持つことはできません。また、非常に長い時間実行されるBACKUPコマンドは必要ありません。
単一のローカルバックアッププランと、AZCopyを使用して結果のバックアップファイルの一部またはすべてをAzureBlobストレージにプッシュするセカンダリジョブを用意するだけです。
このトピックに関する古いブログ投稿は次のとおりです AzCopyを使用したSQL ServerバックアップのWindowsAzureストレージへのコピー 。新しい Azure File Sync サービスを試して、ファイルをAzureに自動的に移動することもできます。