現在、アプリケーションをAzureに移植する前に、SQLデータベースのバックアップ戦略に取り組んでいます。現在、SQL Serverのメンテナンスタスクを使用して、オンプレミスデータベースのバックアップを15分ごとに1時間保持して実行しています（したがって、4つのローカルコピーを保持しています）。また、AmazonS3にプッシュされる24時間のバックアップを実行します。
これまでのところ、Azureでは、次のT-SQLを使用してプライマリデータベースのバックアップを（別のSQLサーバーインスタンスに）作成することができました。
CREATE DATABASE targetserver.backupName AS COPY OF sourceserver.sourceName
ソースデータベースのサイズは約3GBで、月に約5〜10％拡張されています。私が抱えている問題は、コピープロセスが非常に遅いことです！30分以上前にコピーを開始しましたが、まだ実行中です。これは、15分のバックアップスケジュールを採用することはAzureでは受け入れられないように思われることを意味します。
だから私は他のユーザーといくつかのことを修飾できるかどうか疑問に思っています：
3GBのバックアップが別のサーバーインスタンスに複製されるのに30分以上かかる（そして数える）のは正常ですか？
バックアップをソースと同じサーバーに保持する必要がありますか？Azureポータルを数回クリックすると、多くの重要なデータが消去される可能性があるため、非常に緊張しています。これが「ブラックスワン」イベントであることは知っていますが、すべてを単一のサーバーインスタンスで実行するのは簡単ではありません。
SQL Azureデータベースをバックアップするためのより迅速な方法はありますか？Red-Gateを調べましたが、1日未満の増分バックアップを実行するにはコストがかかるようです。
これについての考えは大歓迎です！
バックアップ戦略を完全に再考して、Azureに対応できるようにしたことを嬉しく思います。重要なのは、管理者のエラーを軽減することです。たとえば、不器用なステートメントが原因で重要なデータの負荷を落としたり（バックアップ間隔が短いほど良い）、24時間バックアップを別のストレージ方法（blobコンテナなど）にプッシュしたりします。
アップデート - - -
1時間待ってから最初のバックアップ要求をキャンセルし、再開しました。2回目のバックアップは5分で完了しました。Red-Gateに戻って、ホストされているバックアップソリューションを確認しました。