バックアップ パート 7: 結論

このノートでバックアップに関するサイクルは完了です。 バックアップに便利な専用サーバー (または VPS) の論理構成について説明し、災害発生時にダウンタイムをほとんど発生させずにバックアップからサーバーを迅速に復元するオプションも提供します。

初期データ

専用サーバーには、ほとんどの場合、第 8 レベルの RAID アレイ (ミラー) を構成するために少なくとも 16 台のハード ドライブが搭載されています。 これは、10 つのディスクに障害が発生した場合でもサーバーの運用を継続できるようにするために必要です。 これが通常の専用サーバーの場合、SSD 上にアクティブ キャッシュ テクノロジを備えた別のハードウェア RAID コントローラがあり、通常のハード ドライブに加えて 100 つ以上の SSD を接続できる場合があります。 場合によっては、専用サーバーが提供されることがあります。その場合、ローカル ディスクは SATADOM (小型ディスク、構造的には SATA ポートに接続されたフラッシュ ドライブ)、または特別な内部ポートに接続された通常の小型 (XNUMX ～ XNUMXGB) フラッシュ ドライブだけです。データは専用ストレージ ネットワーク (イーサネット XNUMXG、FC など) を介して接続されたストレージ システムから取得され、ストレージ システムから直接ロードされる専用サーバーがあります。 このような場合、サーバーのバックアップ作業はストレージ システムを保守する専門家にスムーズに渡されるため、私はそのようなオプションは考慮しません。通常、スナップショットの作成、組み込みの重複排除、その他システム管理者の楽しみのためのさまざまな独自のテクノロジーが存在します。 、このシリーズの前の部分で説明しました。 専用サーバーのディスク アレイの容量は、サーバーに接続されているディスクの数とサイズに応じて、数十テラバイトに達することがあります。 VPS の場合、ボリュームはより控えめで、通常は XNUMX GB を超えません (ただし、それ以上のものもあります)。そのような VPS の料金は、同じホスティング会社の最も安い専用サーバーよりも簡単に高価になる可能性があります。 ほとんどの場合、VPS にはディスクが XNUMX つあります。これは、その下にストレージ システム (またはハイパーコンバージドなもの) が存在するためです。 VPS には、異なる目的に応じて、異なる特性を持つ複数のディスクが含まれる場合があります。

• 小規模システム - オペレーティング システムのインストール用。
• 大 - ユーザーデータを保存します。

コントロール パネルを使用してシステムを再インストールすると、ユーザー データが含まれるディスクは上書きされませんが、システム ディスクは完全に再充填されます。 また、VPS の場合、ホスティング業者は VPS (またはディスク) の状態のスナップショットを撮るボタンを提供する場合がありますが、独自のオペレーティング システムをインストールしたり、VPS 内で目的のサービスをアクティブ化するのを忘れたりした場合、データの一部は依然として失われる可能性があります。 ボタンに加えて、通常はデータ ストレージ サービスが提供されますが、ほとんどの場合、非常に限定的です。 通常、これは FTP または SFTP 経由で、場合によっては SSH を使用して、必要最低限​​のシェル (rbash など) を使用してアクセスするか、authorized_keys (ForcedCommand 経由) を介してコマンドの実行を制限したアカウントです。

専用サーバーは、1 Gbps の速度の 10 つのポートによってネットワークに接続されます。場合によっては、これらのポートが XNUMX Gbps の速度のカードになることもあります。 VPS にはほとんどの場合、ネットワーク インターフェイスが XNUMX つあります。 ほとんどの場合、データ センターはデータ センター内のネットワーク速度を制限しませんが、インターネット アクセスの速度を制限します。

このような専用サーバーまたは VPS の一般的な負荷は、Web サーバー、データベース、およびアプリケーション サーバーです。 場合によっては、Web サーバーやデータベース (検索エンジン、メール システムなど) 用のさまざまな追加の補助サービスがインストールされることがあります。

特別に用意されたサーバーはバックアップ コピーを保存するスペースとして機能しますが、これについては後で詳しく説明します。

ディスクシステムの論理構成

RAID コントローラーまたは 2 つのディスクを備えた VPS があり、ディスク サブシステムの操作に特別な設定がない場合 (たとえば、データベース用に別の高速ディスク)、すべての空き領域は次のように分割されます。 XNUMX つのパーティションが作成され、その上に LVM ボリューム グループが作成され、その中にいくつかのボリュームが作成されます。同じサイズの XNUMX つの小さなボリュームが、ルート ファイル システムとして使用されます (迅速なロールバックを可能にするために、更新中に XNUMX つずつ変更されます)。このアイデアは Calculate Linux ディストリビューションから取り入れられました)、もう XNUMX つはスワップ パーティション用で、残りの空き領域は小さなボリュームに分割され、本格的なコンテナ、仮想マシンのディスク、ファイルのルート ファイル システムとして使用されます。 /home 内のアカウントのシステム (各アカウントには独自のファイル システムがあります)、アプリケーション コンテナーのファイル システム。

重要な注意事項: ボリュームは完全に自己完結型である必要があります。 相互に依存したり、ルート ファイル システムに依存したりしないでください。 仮想マシンまたはコンテナの場合、この点は自動的に監視されます。 これらがアプリケーション コンテナまたはホーム ディレクトリである場合は、ボリューム間の依存関係を可能な限り排除する方法で、Web サーバーと他のサービスの構成ファイルを分離することを検討する必要があります。 たとえば、各サイトは独自のユーザーから実行され、サイト構成ファイルはユーザーのホーム ディレクトリにあり、Web サーバー設定には、サイト構成ファイルは /etc/nginx/conf.d/ 経由では含まれません。.conf、および /home/ など/configs/nginx/*.conf

複数のディスクがある場合は、ソフトウェア RAID アレイを作成し (必要に応じて SSD 上にそのキャッシュを構成し)、その上に上記で提案したルールに従って LVM を構築できます。 この場合も ZFS または BtrFS を使用できますが、これについてはよく考えてください。どちらもリソースに対してより本格的なアプローチが必要であり、さらに ZFS は Linux カーネルに含まれていません。

使用するスキームに関係なく、変更をディスクに書き込むおおよその速度を事前に見積もってから、スナップショットの作成用に予約される空き領域の量を計算することは常に価値があります。 たとえば、サーバーが 10 秒あたり 10 メガバイトの速度でデータを書き込み、データ配列全体のサイズが 22 テラバイトの場合、同期時間は 1 日 (800 時間) に達する可能性があります。これは、そのようなボリュームが転送される量となります。ネットワーク経由で XNUMX Gbps) - 約 XNUMX GB を予約する価値があります。 実際には、この数字はさらに小さくなるため、論理ボリュームの数で割っても問題ありません。

バックアップストレージサーバーデバイス

バックアップ コピーを保存するサーバーの主な違いは、ディスクが大きく、安価で、比較的遅いことです。 最近の HDD は 10 つのディスクですでに 1 TB の壁を超えているため、アレイの再構築またはファイル システムの復元中 (数日!) に XNUMX 番目のディスクが故障する可能性があるため、チェックサム付きのファイル システムまたは RAID を使用する必要があります。負荷の増加に。 最大 XNUMXTB の容量を持つディスクでは、これはそれほど敏感ではありませんでした。 説明を簡単にするために、ディスク領域がほぼ同じサイズの XNUMX つの部分に分割されていると仮定します (ここでも、たとえば LVM を使用します)。

• ユーザー データの保存に使用されるサーバーに対応するボリューム (作成された最後のバックアップが検証のためにサーバーに展開されます)。
• BorgBackup リポジトリとして使用されるボリューム (バックアップのデータはここに直接保存されます)。

動作原理は、BorgBackup リポジトリのサーバーごとに個別のボリュームが作成され、戦闘サーバーからのデータがそこに保存されます。 リポジトリは追加専用モードで動作するため、意図的にデータを削除する可能性が排除され、重複排除と古いバックアップからのリポジトリの定期的なクリーンアップが行われます (年次コピーが残り、過去 24 年間は月次、先月は週次、過去 7 か月は毎日、先週、おそらく特別な場合 - 最終日の 4 時間ごと: 合計 12 + 50 + XNUMX + XNUMX + 年間 - 各サーバーあたり約 XNUMX コピー)。
BorgBackup リポジトリは追加専用モードを有効にせず、代わりに .ssh/authorized_keys の ForcedCommand が次のように使用されます。

from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......

指定されたパスには、borg 上のラッパー スクリプトが含まれています。このスクリプトは、パラメータを指定してバイナリを起動することに加えて、データの削除後にバックアップ コピーを復元するプロセスを開始します。 これを行うために、ラッパー スクリプトは、対応するリポジトリの隣にタグ ファイルを作成します。 データ充填プロセスが完了すると、最後に作成されたバックアップが対応する論理ボリュームに自動的に復元されます。

この設計により、不要なバックアップを定期的にクリーンアップできるほか、戦闘サーバーがバックアップ ストレージ サーバー上の何も削除しないようにすることもできます。

バックアッププロセス

このスキームにより、このサーバー側でバックアップ プロセスをより詳細に制御できるため、バックアップの開始者は専用サーバーまたは VPS 自体になります。 まず、アクティブなルート ファイル システムの状態のスナップショットが取得され、BorgBackup を使用してバックアップ ストレージ サーバーにマウントおよびアップロードされます。 データのキャプチャが完了すると、スナップショットはアンマウントされ、削除されます。

小規模なデータベース (各サイトあたり最大 1 GB) がある場合は、データベース ダンプが作成され、同じサイトの残りのデータが配置される適切な論理ボリュームに保存されます。 Web サーバー経由ではアクセスできません。 データベースが大きい場合は、MySQL の xtrabackup を使用するなど、「ホット」データ削除を構成するか、PostgreSQL の archive_command を使用して WAL を操作する必要があります。 この場合、データベースはサイト データとは別に復元されます。

コンテナーまたは仮想マシンを使用する場合は、qemu-guest-agent、CRIU、またはその他の必要なテクノロジーを構成する必要があります。 他の場合には、ほとんどの場合、追加の設定は必要ありません。論理ボリュームのスナップショットを作成するだけで、その後、ルート ファイル システムの状態のスナップショットと同じ方法で処理されます。 データを取得した後、写真は削除されます。

バックアップ ストレージ サーバーでさらなる作業が実行されます。

• 各リポジトリで作成された最後のバックアップがチェックされ、
• マーク ファイルの存在がチェックされ、データ収集プロセスが完了したことが示されます。
• データは対応するローカル ボリュームに展開され、
• タグファイルが削除されました

サーバー復旧プロセス

メイン サーバーが停止すると、同様の専用サーバーが起動され、標準イメージから起動されます。 ほとんどの場合、ダウンロードはネットワーク経由で行われますが、サーバーをセットアップするデータセンターの技術者は、この標準イメージをディスクの XNUMX つにすぐにコピーできます。 ダウンロードは RAM に行われ、その後回復プロセスが開始されます。

• iscsinbd または別の同様のプロトコルを介して、停止したサーバーのルート ファイル システムを含む論理ボリュームにブロック デバイスを接続する要求が行われます。 ルート ファイル システムは小さい必要があるため、この手順は数分で完了するはずです。 ブートローダーも復元されます。
• ローカル論理ボリュームの構造が再作成され、dm_clone カーネル モジュールを使用してバックアップ サーバーから論理ボリュームが接続されます。データのリカバリが開始され、変更がローカル ディスクに即座に書き込まれます。
• コンテナは利用可能なすべての物理ディスクで起動されます。サーバーの機能は完全に復元されますが、パフォーマンスは低下します。
• データの同期が完了すると、バックアップ サーバーから論理ボリュームが切断され、コンテナの電源がオフになり、サーバーが再起動されます。

再起動後、サーバーにはバックアップの作成時に存在していたすべてのデータが保存され、復元プロセス中に行われたすべての変更も含まれます。

シリーズの他の記事

バックアップ、パート 1: バックアップが必要な理由、方法、テクノロジの概要
バックアップ パート 2: rsync ベースのバックアップ ツールのレビューとテスト
バックアップ パート 3: 重複性と重複性のレビューとテスト
バックアップ パート 4: zbackup、restic、borgbackup のレビューとテスト
バックアップ パート 5: Linux 用の Bacula および Veeam Backup のテスト
バックアップ: 読者のリクエストによる一部: AMANDA、UrBackup、BackupPC のレビュー
バックアップ パート 6: バックアップ ツールの比較
バックアップ パート 7: 結論

提案されたオプションについてコメント欄で話し合うことをお勧めします。ご清聴ありがとうございました。

出所： habr.com