クラウド間のDBバックアップを行うかご意見をください

小規模なB2Bシステムを開発しており、AWSを使っています。DBはRDS MySQLです。
DBバックアップをRDSスナップショットとダンプのS3保存で行っていますが、結局は同システム内での話のため、AWS外にも置いた方が良いのか？と悩んでいます。

ディザスタリカバリだけ考えれば別リージョンで良さそうなのですが、AWSの大規模障害が起きたら？と考えると、AWS外別クラウドかオンプレかの方が良いのかなと。
一方で、よほど運が悪くなければ停止も1，2日位で復旧しそうで、RDSとS3両方のデータが消失するリスクも高くなく、逆にセキュリティリスク増えるだけでは？という気持ちもあり、やるかを悩んでいます。

(例は知らないのですが、ログイン回りなど共通部分が死んだらどのリージョンもも使えない事もおきるのかなと)

お聞きしたいこと

皆さんの仕事では、AWS等クラウド環境から、別クラウド(または自社オンプレでも)へのDBバックアップはされてますでしょうか？
していない場合、検討したうえで不要とされましたでしょうか？
変な質問で恐縮ですが、ぜひご教示いただければ。

補足情報

今回気にしているバックアップの目的は、データ喪失やサービス停止が長引くリスクを下げたい、というものです。
(単にデータ壊れた場合などの復旧であれば、普通にAWS内で問題ないと思います)

コードはgithubにあり、環境もDockerfileで再現できます。
ドメインも偶然ですが別サービスで管理しているので、DBさえあればAWS完全死亡しても
一応の復旧はできる状態ではあります。

行動規範の内容に同意します

回答1件

ベストアンサー

別環境へのバックアップは取らないよりは取る方が良いのは確実ではあります。
とは言えリソースは有限なのでリスクを精査してコストとの天秤にかけ、最終的なサービス可用性を定義するしかありません。

予算が足りなかったり、2-3日止まっても諦められるサービスならやらないですし、すぐに復旧が必要なサービスならバックアップに限らず可用性を向上させる施策を行います。

リスクの精査とは例えば

今回気にしているバックアップの目的は、データ喪失やサービス停止が長引くリスクを下げたい、というものです。

の場合だと「データ喪失やサービス停止が長引くリスク」とざっくり括るのでは無く「データ喪失やサービス停止が長引くとどんな損害がどの程度発生するか」を精査することです。

コストとはそのサービス可用性を実現するための初期コストと運用コストを指します。
バックアップだけあってもすぐにサービスを再開できる訳ではないので、マルチクラウドで可用性を確保しようとすると馬鹿にならないコストが発生します。
他のクラウドへのデプロイの自動化(初期費用)やホットスタンバイしておいて(ランニングコスト)DNSを自動で切り替える仕組み(初期費用)を作ったりとかですね。

まずは、何となく定義されているであろう可用性に関する要件を明確にして基準を作るところから手をつけるのが良いかと思いますよ。

投稿2020/12/06 11:33

編集2020/12/06 12:16