最近、Alteryx Serverのバックアップが利用できなかったためにデータ損失をもたらすいくつかの状況に遭遇しました。サーバーを定期的にバックアップすることの重要性はいくら強調しても足りません。2回シリーズの第1回目となるこの記事では、必要な場合に必要なバックアップを利用できるようにするためのオプションとベストプラクティスについて説明します。Part2では、Alteryx Serverのインストール時に組み込まれるMongoDBインスタンスに焦点を当てます。ユーザー管理のMongoDBインスタンスを利用している場合は、MongoDBのバックアップおよびリカバリ手順のドキュメントをこちらからご参照ください。https://docs.mongodb.org/manual/administration/backup/
サーバーとデータベースをバックアップするために、広く受け入れられているベストプラクティスをいくつか見てみましょう：
定期的にバックアップをスケジュールする - データの損失とダウンタイムを最小限に抑えるためには、定期的にバックアップをとることが重要です。ユーザーへの潜在的な影響を最小限に抑え、クラッシュやその他の障害が発生した場合のデータ損失を最小限に留めるために、ピーク時を避け、夜間にバックアップすることをお勧めします。夜間のバックアップが実行できない場合は、週単位でのバックアップのスケジュール設定も可能です。重要なのは、定期的なスケジュールを設定することです。
過去のバックアップを一定期間保存する - バックアップの失敗、破損、紛失/削除、または問題にすぐに気付かなかったりする（バックアップに問題の状態が存在してしまう）といった予期せぬ事態が発生することがあるためです。過去のバックアップがあると、バックアップを確実に利用できるようになり、問題が発生する前に作成したバックアップを選択できるようになります。
ネットワークまたはSANストレージにバックアップを保存する - データが存在する場所と同じサーバーにバックアップを保存すると、障害発生時にそれらのバックアップが使用できなくなる危険性があります。サーバーにディスク障害が発生したときにどうなるかを考えてみましょう。バックアップがローカルディスクに保存されている場合は、それらも削除されてしまうためリカバリは不可能です。 しかし、バックアップがネットワーク上に保存されている場合は、サーバー上の障害イベントによる影響はありません。
バックアップのコピーをオフサイトに保管する - これは上記と同じ理由によるものです。唯一のバックアップがAlteryx Serverと同じデータセンター内のファイルサーバー上にあり、そのデータセンターが災害を被った場合、サーバーとバックアップの両方が失われます。追加のコピーをオフサイトに保存しておくことで、必要に応じてサーバーバックアップをクラウドまたは別のデータセンターに持っていくことができます。
バックアップファイルを検証する - バックアップが正常に行われていることを定期的に確認し、バックアップが有効で使用可能であることを確認する必要があります。バックアッププロセスを実行して、障害が発生した時にバックアップが6か月前に機能しなくなったことが発覚したり、あるいは、すべてのバックアップが使用できないことを知ることほど最悪なことはありません。
回復手順を定期的に実践する - 回復訓練により、回復プロセスや災害時に完全に機能する状態に戻るのに必要とされる時間を熟知することができます。訓練により、間違いの発生を減らすことも証明されており、貴重な時間を節約することができます。四半期ごとまたは年に2回は回復訓練を実施することをお勧めします。
ほとんどの場合、OSとすべてのデータを含むサーバー全体をバックアップする必要はありません。実際、サーバー全体のバックアップを行うと平均復旧時間が大幅に長くなる可能性があります。その代わりに、サーバーの重要なデータと構成ファイルのみをバックアップすることをお勧めします。これは、サーバー全体を復元するよりも、サーバーと必要なソフトウェアをクリーンインストールしてからバックアップしたデータや設定を復元したほうが、復旧にかかる時間を大幅に短縮することができるからです。これは仮想サーバーの場合に特に当てはまります。ほとんどの場合、新しい仮想サーバーの展開には数分かかるからです。これらの限定的なバックアップでは、バックアップの完了と検証にかかる時間を短縮し、それらのバックアップを維持するために必要なストレージのニーズとコストを削減することもできます。
Part2 - Alteryx Serverのバックアップとリカバリ Part2: 手順
