バックアップは、あらゆるアイアンで叫ばれているような流行のテクノロジーの XNUMX つではありません。 真面目な会社であればいい、それだけです。 私たちの銀行では数千台のサーバーをバックアップしています。これは複雑で興味深い仕事ですが、その微妙な点や、バックアップに関するよくある誤解については、ぜひ知っておいていただきたいと思っています。
私はこのテーマに約 20 年間取り組んできましたが、そのうちの 2 年間はプロムスヴィヤズ銀行に勤務していました。 実践を始めた当初は、ファイルをコピーするだけのスクリプトを使用して、ほぼ手動でバックアップを作成していました。 その後、ファイルを準備するための Robocopy ユーティリティとコピーのための NT Backup という便利なツールが Windows に登場しました。 そして、特殊なソフトウェア、主に Veritas Backup Exec (現在は Symantec Backup Exec と呼ばれています) の時代が来ました。 そのため、私はバックアップについては長い間慣れ親しんでいました。
簡単に言えば、バックアップとは、一定の規則性を持って万が一に備えてデータ (仮想マシン、アプリケーション、データベース、ファイル) のコピーを保存することです。 通常、各ケースはハードウェアまたは論理障害として現れ、データ損失が発生します。 バックアップ システムの目的は、情報の損失を軽減することです。 ハードウェア障害とは、たとえば、データベースが配置されているサーバーまたはストレージの障害です。 論理的 - これは、テーブルやファイルを誤って削除したり、実行のために不正なスクリプトを起動したりするなど、人的要因によるデータの一部の損失または変更です。 特定の種類の情報を長期間 (たとえば、最大数年間) 保存するための規制要件もあります。
バックアップの最も一般的な使用法は、開発者向けのさまざまなテスト システムやクローンを展開するために保存されたデータベースのコピーを復元することです。
バックアップに関しては、ずっと前に払拭されるべき典型的な通説がいくつかあります。 その中で最も有名なものを以下に挙げます。
通説 1. バックアップは長い間、セキュリティ システムまたはストレージ システム内の小さな機能にすぎませんでした
バックアップ システムは依然として別のクラスのソリューションであり、非常に独立しています。 彼らにはやるべきことが多すぎる。 実際、データの整合性に関しては、これらは最後の防御線です。 したがって、バックアップは独自のペースで、独自のスケジュールで動作します。 サーバーの日次レポートが生成され、監視システムのトリガーとして機能するイベントがあります。
さらに、バックアップ システムへのアクセスのロール モデルにより、バックアップを管理する権限の一部をターゲット システムの管理者に委任できます。
誤解 2. RAID がある場合、バックアップは必要ありません。
RAID アレイとデータ レプリケーションは、ハードウェア障害から情報システムを保護するための優れた方法であることは間違いありません。また、スタンバイ サーバーがある場合は、メイン マシンに障害が発生した場合に備えて、すぐにスタンバイ サーバーに切り替えることができます。
システムのユーザーによって発生した論理エラーからは、冗長性とレプリケーションは保存されません。 これはライトバック スタンバイ サーバーです。はい、同期前にエラーが検出された場合に役立ちます。 そして、その瞬間を逃したら？ ここではタイムリーなバックアップのみが役に立ちます。 データが昨日変更されたことがわかっている場合は、システムを一昨日の状態に復元し、そこから必要なデータを抽出できます。 論理エラーが最も一般的であるという事実を考慮すると、古き良きバックアップは実証済みの必要なツールであり続けます。
誤解 3. バックアップは月に XNUMX 回実行されるものです。
バックアップ頻度は構成可能な設定であり、主にバックアップ システム要件に依存します。 ほとんど変更されず、特に重要ではないデータが見つかる可能性は十分にありますが、その損失は会社にとって重大なものではありません。
実際、バックアップは月に XNUMX 回、またはそれより少ない頻度で行うことができます。 ただし、許容されるデータ損失を設定する RPO (目標復旧時点) 指標に応じて、より重要なデータがより頻繁に保存されます。 これは、週に XNUMX 回、XNUMX 日 XNUMX 回、または XNUMX 時間に数回の場合もあります。 これらのトランザクション ログは DBMS から取得されます。
システムを商用運用する場合には、更新手順、システムの復元手順、バックアップの保存手順などの要点を反映したバックアップ文書の承認が必要です。
誤解 4. コピーの量は常に増加しており、割り当てられたスペースを完全に占有します。
バックアップには制限された保存期間があります。 たとえば、年間 365 日のバックアップをすべて保存するのは意味がありません。 原則として、毎日のコピーを 2 週間保持することができます。その後、新しいコピーに置き換えられ、月の最初に作成されたバージョンが長期保管されます。 また、コピーは一定期間保存されます。各コピーには有効期間があります。
データ損失保護機能があります。 ルールが適用されます。バックアップを削除する前に、次のバックアップを作成する必要があります。 したがって、サーバーが利用できないなどの理由でバックアップが完了していない場合、データは削除されません。 時間枠が尊重されるだけでなく、セット内のコピー数も管理されます。 システムが XNUMX つの完全バックアップを持つように設計されている場合、それらは常に XNUMX つ存在し、新しい XNUMX 番目のバックアップが正常に書き込まれた場合にのみ古いバックアップが削除されます。 したがって、バックアップ アーカイブが占めるボリュームの増加は、保護されるデータの量の増加のみに関連し、時間には依存しません。
通説 5. バックアップが開始された - すべてがハングした
これは言ったほうがいいでしょう。すべてがぶら下がっている場合、管理者の手はそこから伸びません。 一般に、バックアップのパフォーマンスは多くの要因に依存します。 たとえば、バックアップ システム自体の速度、つまりディスク ストレージやテープ ライブラリの速度についてです。 バックアップ システムのサーバーの速度から、データの処理、圧縮、重複排除の実行に時間があるかどうか。 また、クライアントとサーバー間の通信回線の速度も関係します。
バックアップ対象のシステムがマルチスレッドをサポートしているかどうかに応じて、バックアップは XNUMX つ以上のストリームに送信されます。 たとえば、Oracle DBMS では、転送速度がネットワーク帯域幅の制限に達するまで、使用可能なプロセッサの数に応じて複数のスレッドを割り当てることができます。
多数のスレッドをバックアップしようとすると、実行中のシステムに過負荷がかかる可能性があり、実際に速度が低下し始めます。 したがって、十分なパフォーマンスを確保するために最適なスレッド数が選択されます。 わずかでもパフォーマンスの低下が重要な場合は、戦闘サーバーからではなく、そのクローン (データベース用語でいうスタンバイ) からバックアップを実行するという優れたオプションがあります。 このプロセスでは、メインの動作システムは起動しません。 サーバーはメンテナンスに使用されないため、より多くのストリームを通じてデータを取得できます。
大規模な組織では、バックアップが本番環境に影響を与えないように、バックアップ システム用に別のネットワークが作成されます。 さらに、トラフィックはネットワーク経由ではなく、SAN 経由で送信される場合があります。
時間の経過とともに負荷を分散することにも努めます。 バックアップは主に夜間や週末などの勤務時間外に行われます。 また、それらはすべて同時に実行されるわけではありません。 仮想マシンのバックアップは特殊なケースです。 このプロセスはマシン自体のパフォーマンスには実質的に影響を与えないため、バックアップは日中に分散でき、すべてを夜間に延期する必要はありません。 多くの微妙な点がありますが、すべてを考慮に入れれば、バックアップはシステムのパフォーマンスに影響を与えません。
誤解 6. バックアップ システムを立ち上げた - それがあなたにとってのフォールト トレランスです
バックアップ システムは最後の防御線であることを決して忘れないでください。つまり、IT インフラストラクチャと企業情報システムの継続性、高可用性、耐災害性を確保するには、その前にさらに XNUMX つのシステムが必要です。
バックアップによってすべてのデータが復元され、障害が発生したサービスがすぐに復旧することを期待する価値はありません。 バックアップの瞬間から障害の瞬間までのデータ損失が保証されており、データは数時間 (運が良ければ数日) 新しいサーバーにアップロードできます。 したがって、すべてをバックアップに移行せずに、本格的なフォールト トレラント システムを構築することは理にかなっています。
誤解 7. バックアップを一度セットアップし、それが機能することを確認しました。 あとはログを見るだけです
これは最も有害な通説の XNUMX つであり、事件の最中に初めてその偽りに気づくことになります。 ログのバックアップが成功しても、すべてが実際に正常に行われたことを保証するものではありません。 保存されたコピーが展開可能かどうかを事前に確認することが重要です。 つまり、テスト環境で回復プロセスを開始し、結果を確認します。
システム管理者の仕事について少し
手動モードでは、長い間データをコピーする人はいませんでした。 最新の SRK は、適切に設定するだけで、ほぼすべてのものをバックアップできます。 新しいサーバーが追加された場合は、ポリシーを設定します。バックアップするコンテンツを選択し、ストレージ オプションを指定し、スケジュールを適用します。
同時に、Windows と Linux / Unix 上のデータベース、メール システム、仮想マシン クラスタ、ファイル共有など、膨大な数のサーバーが存在するため、まだ多くの作業が必要です。 バックアップ システムを稼働させ続ける従業員は、手をこまねいているわけではありません。
休日を記念して、すべての管理者に強い神経、動きの明瞭さ、そしてバックアップを保存するための無限のスペースを祈りたいと思います。
出所： habr.com