完全なバックアップシステムには何が必要ですか？
新しいサーバーでは、適切なバックアップソリューションをセットアップしたいと思います。 Dropboxを介して1日2回の増分バックアップを実行する優れたセットアップを見つけました。さまざまなデータベース、webrootディレクトリ、/ etcディレクトリ/リポジトリ、および/ var/logをバックアップする予定です。
適切なバックアップを実行するために他に何を知る必要がありますか？また、システム障害が発生した場合にバックアップから迅速に復元できるようにするための標準的な設定は何ですか？
システムのあり方を説明しているPuppetの使用を考えています。私の復元手順は次のようになります。
- Puppetをインストールする
- Puppetconfigを実行します
- Dropboxからバックアップを復元します（これを行うためのスクリプトを作成する必要がありますか？おそらく）
これにより、開発環境で使用するための本番サーバーのクローンも作成できるはずですよね？重要なものが欠けていますか？
バックアップシステムは、復元を有効にするという1つの目的で構築されています。誰もバックアップを気にしません。彼らは復元を気にします。
ファイルを復元する必要がある理由は3つあります。偶発的なファイルの削除、ハードウェア障害、またはアーカイブ/法的理由です。 「完全な」バックアップシステムを使用すると、これらすべてのシナリオでファイルを復元できます。
誤ってファイルを削除した場合、DropboxやRAIDなどはファイルシステムに加えられたすべての変更を反映しているだけなので失敗し、削除されたファイルはこれらのシナリオでは失われます。バックアップシステムは、ファイルをかなり迅速に最近の時点に復元できる必要があります。復元は数秒から数分以内に完了することが望ましいです。
システムの完全な復元には読み取りと書き込みの必要性のために数時間または場合によっては数日かかる可能性があるため、ハードウェア障害の場合は、可能な場合はRAIDやその他の高可用性アプローチなどのソリューションを使用してサービスが稼働し続けるようにする必要があります。 （比較的）遅いメディアに。
最後に、特定の時点でのシステムのアーカイブまたは完全バックアップ（または同等のもの）は、法的シナリオと災害復旧シナリオの両方で復元を提供できます。これらは通常、漂遊流星がデータセンターを喫煙クレーターに変えた場合に備えて、オフサイトに保管されます...
完全なバックアップシステムは、さまざまなサービスレベル（SLA）で、これら3つのタイプのいずれかの復元をサポートできる必要があります。たとえば、削除されたファイルを、過去6か月間は1営業日、過去3年間は1か月の粒度で復元できると判断できます。また、ディスク障害は、2営業日以内のデータ損失で4時間以内に復元できる必要があります。バックアップシステムは、バックアップスケジュールにSLAを実装できる必要があります。
バックアップシステムは完全に自動化されている必要があります。これは十分に強調することはできません。バックアップが完全に自動化されていない場合、バックアップは実行されません。バックアップシステムは、特別な構成やスクリプトをほとんどまたはまったく必要とせずに、箱から出して完全に自動化されたバックアップに対応している必要があります。
復元を定期的にテストする必要があります。バックアップからの復元が機能しない場合、バックアップシステムはまったく役に立ちません。私たちのほとんどは、これらの線に沿ってホラーストーリーを持っていると思います。バックアップシステムは、実装しているSLA内の単一のファイルまたはシステム全体を復元できる必要があります。
バックアップメディアは継続的に購入する必要があります。オンサイトのテープバックアップを実行している場合でも、オフサイトのクラウドバックアップを使用している場合でも、必要なギガバイト（またはテラバイト！）のスペースを支払う予算内にあることを確認してください。
これは、 システムおよびネットワーク管理の実践、第2版 の第26章の一部の非常に簡単な要約であり、システム管理者になるには、所有、読み取り、および記憶する必要があります。
私はあなたの特定の状況に必ずしも当てはまらない、またはあなたが説明したような小さな環境では意味をなさない多くのことをざっと見てきました。それでも、「完全な」バックアップシステムに必要な機能と、それらが必要な理由を合理的に説明する必要があります。
- DropBoxは、バックアップを行うための危険な方法です。 SLA/QoSはなく、自動化された方法で大量のデータをサーバーにダンプすることは、おそらく通常のTOSに反します。彼らはあなたのデータにアクセスする際のいかなる責任も明確に否認します-彼らは彼ら自身の裁量でそして警告なしにアクセスを遮断したり、データを破壊したり、破産したりするかもしれません。
- 実際に復元するまで、バックアップ手順は「有効」ではありません。それが確実な唯一の方法です。多くのほとんどのバックアップソフトウェアは「検証」機能を提供します。これは、何かがバックアップメディアに書き込まれたことを検証するだけなので、ほとんどの人にとって役に立たないよりも悪いです。 notsomethingが実際に運用システムの復元に役立つこと。
- 執拗に完全なドキュメントにより、災害が発生したときに復元手順に従うことができます。ドキュメントのテストは、システムの復元のテストの一部である必要があります。また、あなたがバスにぶつかった場合、他の誰かが手続きを完了することができます（マーフィーの法則など）。
- 復元は、意味のある期間内に実行できる場合にのみ役立ちます。たとえば、役に立たないデータを復元するのに1年かかった場合。最小限の機能、日常の操作、完全な3つのレベルの機能について、状況に必要な時間枠を決定する必要があります。提案されたソリューションをテストし、時間要件に適合するかどうかを確認します。
RAID、およびDropboxのようなサービスは変更を「バックアップ」すべてします。バックアップを使用して回復したい間違いを含みます。
これが、すべてのシステム管理者タイプが、ファイルへの変更のミラーリングに依存するRAIDやtoytownクラウドファイルストレージサービスのようなものがnotバックアップである理由について非常に腹を立てている理由です。これらのサービスが役に立たないというわけではありません。それらはそうですが、実際にはデータの整合性を提供しないため、バックアップではありません。
バックアップは、バックアップが作成されたときの状況のスナップショットである必要があります。データに発生するすべての良い点と悪い点のライブログが継続的に上書きされるのではありません。見れば実際のバックアップを提供するクラウドプロバイダーがあり、それらはドロップボックス/スカイドライブタイプのサービスとは異なる働きをします。
結局のところ、それらのリスクを軽減するための予算に対して、どのような種類のリスクにさらしても構わないと思っているかはあなたの選択です。 Dropboxのようなもので十分だと思うなら、それはあなた次第です。しかし、それがあなたのために何をするのか、何をしないのかを明確にする必要があります-それが本当のバックアップであると自分自身をからかってはいけません。
いや。あなたは今のところ元気です。少なくともコンセプトは...
- バックアップ時のシステムの状態について考えてください。おそらく、ライブデータベースをバックアップしたくないでしょう...
- または、ハードウェアについて考えてください。マシンを可能な限り弾力性のあるものにするために、できる限りのことをしていますか？たとえば、緊急時にバックアップから復元することを最後にしたいと思います。
- 高品質のハードウェアを使用することで、停止や小規模なサービスの停止を減らすことができるため、RAID、サーバークラスの機器を使用し、データ保護に対するよりローカルなアプローチを検討していることを確認してください。
- 保護している障害の種類と状況について考えてください。
- 私は必ずしもDropBoxを使うとは限りませんが、オフサイト保護のideaは正しいです。
私が好んで試した真のバックアップシステムは次のとおりです。
- すべてのデータベースの1時間ごとのスナップショット（および1日あたり2週間アーカイブされたスナップショット1つ、1週間あたり1年間アーカイブされたスナップショット1つ）。
- 使い捨てサーバー。つまり、すべてのサーバースタンドアップはgitに保存され、自動的にデプロイされます（puppetで言っていることと非常によく似ていますが、推奨されるツールはchefです）。基本的に、新しいサーバーは、使用しているコードのみを使用してゼロから立ち上げることができます。 gitでは、開発ホストは本番サーバーと同様の方法で構築されます。
このような場合のpuppetmasterまたはchefサーバーは、潜在的な障害点になる可能性があります。繰り返しになりますが、可能な限り再構築を自動化し、古いボックスがノックされた場合に、既存のノードが新しいサーバー管理ホストにできるだけ早くbootstrapできるようにするスクリプトを用意しますこの種のホストをバックアップから再構築する方が、新しいホストを最初から立ち上げるよりも大幅に時間がかかる場合があります（バックアップから復元すると、ダウンの原因となった同じ欠陥や問題が意図せずに再発生する可能性があります。そもそも。）
別の言い方をすれば、サーバーやホストなどが2つ以上ある場合は、中央のログサーバーを使用する価値があります。それらが1つのソースから格納（およびバックアップ）されている場合、残りのホストにログを積み上げてスペースをとるという頭痛の種を軽減できます。ログデータはゴールドですが、20台のAPIサーバーがすべてトラフィックを処理していて、DDoSのようなものに見舞われた場合、ログの集計がないということは、干し草の山で針を探していることを意味します。インフラストラクチャログを保存する場合（そしてそうする必要があります！）、1つの堅牢なバックアッププラットフォームに一度保存します。
頑張って〜！