この記事は私の過去の話です。私は以前、コンピューターのハードウェアとソフトウェアを販売するオンラインショップを経営している会社のシステム管理者として働いていました。
後ろでは、何十人もの従業員がターミナルサーバーを使用して、すべての商品と取引を管理するERPソフトウェアを操作していました。ターミナルサーバーとデータベースは、当社の製品を販売するビジネスプロセスにとって重要でした。これらのシステムの1つに障害が発生すると、数十人の従業員が仕事をすることができなくなり、顧客は何も購入できなくなりました。
どれくらいありますか？
そこで、ビジネスプロセスの所有者と話し合い、「システムが壊れて使用できなくなった状況を考えてみてください。会社に壊滅的な打撃を与えるまで、どのくらいの期間回復する必要がありますか？」マネージャーはしばらく考えて、「最大2時間！」と言いました。
私たちはERPアプリケーションを実行している人たちと一緒に座って、「致命的なシステム障害から回復する必要がある場合、アプリケーションを再インストールしてターミナルサーバーを構成するのにどのくらい時間がかかりますか？」と尋ねました。答えは「最低2日！」でした。ここにギャップが見えると思います。
私にとって最優先事項は、復元時間を2日から2時間未満に短縮することでした。オペレーティングシステム、アプリケーションの再インストール、およびデータバックアップの復元は、時間がかかりすぎるため、オプションではありませんでした。オペレーティングシステム、インストールされているアプリケーション、ライブラリ、データを意味する完全なシステムバックアップを実行できるイメージバックアップアプリケーションを選択しました。このソフトウェアを使用すると、手動でインストールする必要がなく、システムを復元できます。
何が必要ですか？
従来の設定では、誰も作業していない夜間にバックアップを実行します。失敗した場合は、昨夜またはさらに古いバージョンからイメージを復元する必要があります。このシナリオでは、テストにより、完全な復元に5時間かかることが示されました。それは2日よりはましですが、それでも十分ではありません。そして、このアプローチには別の問題が隠されています。夕方にシステムがクラッシュし、昨夜のバックアップから復元する必要がある場合、当日からのすべての変更が失われます。それは私たちのオンラインショップには受け入れられませんでした。さて、私たちの最初の考えは、1時間ごとに増分バックアップを実行することでした。その場合、最後の1時間のデータのみが失われます。しかし、問題を発見したときに、システムを破壊する問題がすでにバックアップイメージにある場合はどうなりますか？さて、これが私たちがしたことです。
もう一度座って、システムの復旧につながる壊滅的な問題を発見するのにかかる時間について話し合いました。私たちは4時間の時間枠で合意しました。要約すると、作業の損失をできるだけ少なくし、最大2時間で復元し、問題が発見されたときにバックアップに問題がないことを確認したいと考えました。この情報を使用して、ソフトウェアベンダーがインスタント復元、シャドウ復元、プリエンプティブ復元、または同様の用語と呼ぶバックアップアプローチを設定しました。 1時間ごとに増分バックアップジョブを実行し、バックグラウンドでバックアップを新しい仮想マシンに復元しました。 1時間ごとに、4時間前のシステムを準備し、終了する必要がありました。したがって、1時間前の増分を復元することを選択した場合、ほぼ準備が整った仮想マシンに復元する必要があるのはわずかな増分のみであるため、完全なシステムの復元よりも時間がかかりません。
そしてその努力は報われました
ある日、休暇中にバーベキューとビールを飲みながら、同僚から電話があり、更新に失敗したためにERPアプリケーションを搭載したターミナルサーバーが壊れていて、更新を実行した人が取るのを忘れたとのことでした。最初にスナップショット。
同僚に伝える必要があるのは、壊れたマシンをシャットダウンし、バックアップ/復元システムのUIを見つけて、復元ジョブを特定することだけでした。最後に、復元が終了する最後の4時間からタイムスタンプを選択する方法を彼に説明しました。復元は30分後に終了し、システムを再び使用できるようになりました。合計30分で活動を再開し、過去2時間程度の作業のみが失われました！素晴らしい！さあ、休暇に戻りましょう。
まとめ
したがって、緊急時の復元に関しては、適切なバックアップおよびリカバリソリューションの時間と費用が十分に費やされていることを覚えておいてください。
[無料のオンラインコース：Red HatEnterpriseLinuxの技術概要。 ]