Azure Storageエンティティ(ブロブ、テーブル、キュー)には回復力が組み込まれていることを知っています。つまり、同じデータセンター内の3つの異なるサーバーにレプリケートされます。さらに、物理的に異なる地理的地域にある別のデータセンターに複製することもできます。この場合、データを失う可能性は、すべての実用的な目的でゼロに近いです。
しかし、ずさんな開発者(またはアルコールの影響下にある開発者)がAzure PortalまたはAzure Storage Explorerツールを使用して誤ってストレージアカウントを削除した場合はどうなりますか?最悪の場合、ハッカーがアカウントを取得してストレージをクリアしたらどうなりますか?削除されたブロブのギガバイトを取得する方法はありますか?どういうわけか、Azureインフラストラクチャがここで提供するエレガントなソリューションが必要だと思いますが、ドキュメントが見つかりません。
私が考えることができる唯一の解決策は、ストレージ全体を定期的に別のサブスクリプション/アカウントにバックアップする独自のプロセス(ワーカーロール)を作成することです。何かご意見は?
よろしく、
アーチル
データをバックアップする場所に応じて、次の2つのオプションがあります。
データをローカルでバックアップする-インフラストラクチャでローカルにデータをバックアップする場合、次のことができます。ストレージクライアントライブラリを使用するか、REST APIまたはb。 Cerebrata Azure Management Cmdlets (開示:私はCerebrataで働いています)などのサードパーティツールを使用します。
クラウド内のデータのバックアップ-最近、Windows Azureストレージチームは、データをローカルにダウンロードせずに、1つのストレージアカウントから別のストレージアカウントにデータをコピーできるAsynchronous Copy Blob機能を発表しました。ここでの問題は、ターゲットストレージアカウントが2012年6月7日以降に作成されることです。この機能の詳細については、Windows Azureブログでご覧いただけます。 http://blogs.msdn.com/b/windowsazurestorage/archive/2012 /06/12/introducing-asynchronous-cross-account-copy-blob.aspx 。
お役に立てれば。
受け入れられた答えは結構ですが、すべてを解読するのに数時間かかりました。
現在、本番環境で使用しているソリューションをまとめました。メソッドBackup()
からWeb Api
を公開します。このメソッドは、毎日(深夜に)Azure WebJob
によって呼び出されます。
元のソースコードを取得し、変更したことに注意してください。
ソースは以下から見つけることができます: https://github.com/ChrisEelmaa/StackOverflow/blob/master/AzureStorageAccountBackup.cs
そして、これは私がコントローラーでそれを使用する方法です(コントローラーはAzure Webジョブからのみ呼び出し可能である必要があることに注意してください-ヘッダーの資格情報を確認できます):
[Route("backup")]
[HttpPost]
public async Task<IHttpActionResult> Backup()
{
try
{
await _blobService.Backup();
return Ok();
}
catch (Exception e)
{
_loggerService.Error("Failed to backup blobs " + e);
return InternalServerError(new Exception("Failed to back up blobs!"));
}
}
注:このコードを投稿の一部として追加したかったのですが、この投稿にコードを追加しようとして6分間無駄になりましたが、失敗しました。フォーマットはまったく機能せず、完全に壊れました。
Azure Data Factoryを使用して、Azureストレージを効果的にバックアップしました。使いやすく、費用対効果が高く、非常にうまく機能します。
データファクトリ(v2)を作成し、データソースへのデータ接続を設定し(現在はAzureテーブル、Azure Blob、Azureファイルをサポートしています)、データコピーパイプラインを設定します。
パイプラインはマージ、上書きなどができ、カスタムルール/ワイルドカードを設定できます。
パイプラインを設定したら、スケジュールトリガーを設定する必要があります。これにより、ニーズに合わせて一定の間隔でバックアップが開始されます。
私は何ヶ月も使用してきましたが、完璧です。コード、VMS、カスタムPowerShellスクリプト、サードパーティソフトウェアはありません。純粋なAzureソリューション。
ブログコンテナのスナップショットを作成してから、特定の時点のバックアップ用のスナップショットをダウンロードできます。
https://docs.Microsoft.com/en-us/Azure/storage/storage-blob-snapshots
スナップショットは、ある時点で取得されたblobの読み取り専用バージョンです。スナップショットは、ブロブのバックアップに役立ちます。スナップショットの作成後、読み取り、コピー、または削除はできますが、変更することはできません。+ blobのスナップショットは、ベースblobと同じです。ただし、blob URIはスナップショットが取得された時刻を示します。たとえば、ページBLOB URIが http://storagesample.core.blob.windows.net/mydrives/myvhd の場合、スナップショットURIは http:// storagesample。 core.blob.windows.net/mydrives/myvhd?snapshot=2011-03-09T01:42:34.9360000Z 。
サードパーティのソリューションを参照することなく、以下の手順を使用してAzureの組み込み機能を使用することで、blobを保護することができます。
Azure Storage Blobsのソフト削除より良い手順は、現在GAにあるソフト削除を有効にすることです: https://Azure.Microsoft .com/en-us/blog/soft-delete-for-Azure-storage-blobs-ga
読み取りアクセスの地理的冗長ストレージ2番目のアプローチは、RA-RGAの地理的複製を有効にすることです。別の地域のセカンダリレプリカの詳細については、こちらをご覧ください。 https://docs.Microsoft.com/en-us/Azure/storage/common/storage-redundancy-grs