他の ArcGIS Enterprise 管理者が実際の展開でバックアップと災害復旧をどのように扱っているかを理解したいと思っています。
これまでのところ、WebGIS DR バックアップには繰り返し次のような課題に直面してきました：
- バックアップ作成には数時間から場合によっては数日かかることがあります。
- 大規模な環境では、バックアップファイルが数百ギガバイトに近づくか、それを超えることがあります。
- バックアップジョブは時折失敗したりタイムアウトしたりし、手動での介入が必要になります。
- リカバリーテストはしばしば時間がかかり、運用上複雑です。
- 環境が拡大し続けるにつれて、バックアップウィンドウの維持がますます困難になっています。
私たちの場合、WebGIS DR バックアップには最大で 約900 GB のデータに対して16時間かかりますため、回復目標を満たすために十分な頻度でバックアップを実行することが困難です。
特に困難なのは、Esri のドキュメントやサポートとのやり取りで一貫して WebGIS DR が ArcGIS Enterprise の公式にサポートされたバックアップおよびリカバリーメカニズムとして位置付けられていることです。
同時に、多くの組織はすでに Azure、AWS、GCP、VMware、ストレージプラットフォーム、またはその他のインフラレベルのソリューションによって提供される成熟したクラウドネイティブバックアップ機能を使用しています。これらの技術は通常以下を提供します：
- より高速なバックアップ実行
- 増分バックアップ
- スナップショットベースのリカバリー
- 実証済みの災害復旧ワークフロー
- 低い運用負荷
ここで正直な疑問が生じます：
特に大規模な Enterprise 展開において、WebGIS DR はインフラレベルのバックアップソリューションに対してどんな実用的な利点を提供するのでしょうか？
私たち自身の災害復旧演習は主にインフラストラクチャバックアップと文書化されたリカバリー手順の組み合わせに依存しています。WebGIS DR は全体戦略の一部として残っていますが、ますます最も遅く、最もリソース集約的で柔軟性に欠けるバックアッププロセスの要素となっています。
コミュニティへの質問
- まだ WebGIS DR を主要な災害復旧メカニズムとして使用していますか？
- WebGIS DR をクラウドネイティブバックアップ（Azure Backup、AWS Backup、スナップショット、VMware スナップショットなど）と組み合わせていますか？
- もしそうなら、本当の災害復旧シナリオで最も信頼しているソリューションはどれですか？
- 定期的な WebGIS DR バックアップから完全に移行し、主にインフラレベルのバックアップに依存している方はいらっしゃいますか？
- そのようなアプローチについて Esri サポートと話し合ったことがありますか？もしあれば、どんな指導を受けましたか？
- 非常に大規模な Enterprise 環境で WebGIS DR が依然として実用的である組織はありますか？
特定の展開についてトラブルシューティングアドバイスを求めているわけではありません。
むしろ、公式推奨されている WebGIS DR の使用と組織が実際に本番環境で運用している内容との間にギャップが広がっているかどうかを理解したいと思っています。
他の方々がこの課題にどのように取り組んできたかをぜひお聞きしたいです。
