午前3時に最悪のシナリオが発生したら
電話が激しく震える。CentOS Stream 9 で稼働している社内で最も重要なデータベースサーバーが突然ダウンした。SSHを試みるが、応答はない。サーバー室に駆けつけると、ハードディスクが赤く点灯している。完全な物理故障だ。冷や汗が止まらない。毎日実行していた rsync や tar のスクリプトは、データファイルしかコピーしていなかったことに気づく。システム構成、カーネル、複雑なライブラリのバックアップはどこにもないのだ。
これは、私がシステム管理者として実際に経験した過酷な現実です。OS全体をゼロから手動で復旧する(ベアメタルリカバリ)には、通常4時間から8時間かかります。自分で書いたスクリプトに、貴重な睡眠時間を賭けてはいけません。災害が発生したとき、唯一の救いとなるのはプロフェッショナルなバックアップソリューションです。
なぜ従来のバックアップ手法は『裏切る』のか?
駆け出しの頃、私はよく cronjob と mysqldump を組み合わせて使っていました。しかし、システムが成長するにつれ、この方法には3つの致命的な弱点があることが分かりました。
- データの不整合: データベースが書き込みを行っている最中にスクリプトが実行されると、バックアップファイルが破損(不整合)しやすくなります。
- 復旧時間 (RTO) の長期化: OSを再インストールし、パッケージを構成し、ユーザーを作成してから、ようやくデータを流し込む必要があります。500GBのサーバーであれば、このプロセスに丸一日かかることもあります。
- 管理の限界: 運用サーバーが10台を超えると、数十個の個別スクリプトのログを確認する作業は苦行でしかありません。
Veeam Agent: CentOS Stream 9 に最適な選択肢
Veeam Agent for Linux は、単にファイルをコピーするだけではありません。カーネルモジュールを使用して、ブロックレベルの「スナップショット」を作成します(イメージレベルバックアップ)。サーバーがオンラインの状態でも、HDD上の各ビットを正確にコピーします。サーバーがクラッシュしても、リカバリメディア(USB/ISO)さえあれば、システム全体を15分前の状態にそのまま戻すことができます。特に、FREE版でも単一サーバー向けの主要な機能をすべて利用できるのが魅力です。
ステップ 1: 環境の準備(非常に重要)
Veeam はスナップショットモジュールをビルドするために、カーネルヘッダーパッケージを必要とします。実行中のカーネルと kernel-devel のバージョンが一致しない場合、インストールは即座に失敗します。以下のコマンドを実行してください。
sudo dnf update -y
sudo dnf install -y epel-release
sudo dnf install -y kernel-devel-$(uname -r) dkms elfutils-libelf-devel gcc make
ヒント: カーネルをアップデートした直後の場合は、まずサーバーを reboot してください。これにより、uname -r が現在動作している最新のカーネルバージョンを正しく返すようになります。
ステップ 2: Veeam レポジトリのインストール
セキュリティを確保するため、Veeam の公式サイトから直接レポジトリを取得します。ネット上の出所不明な RPM ファイルは絶対に使用しないでください。
# EL9用のレポジトリ設定をダウンロード
sudo rpm -ivh https://repository.veeam.com/backup/linux/agent/rpm/el/9/x86_64/veeam-release-el9-1.0.8-1.x86_64.rpm
# Veeam Agentのインストール
sudo dnf install -y veeam
インストール後、veeamsnap(または新しいバージョンでは blksnap)モジュールが準備できているか、lsmod | grep veeam コマンドで確認してください。
ステップ 3: 最初のバックアップジョブの設定
Veeam は直感的な TUI(テキストユーザーインターフェース)を提供しています。以下のコマンドを入力するだけです。
veeamconfig ui
C を押して新しいジョブを作成します。通常はシステム全体をバックアップする Entire Machine を選択することをお勧めします。外付けHDDやNASを使用する場合は、Shared folder を選択してください。実務上のアドバイスとして、ユーザーアクセスへの影響を避けるため、バックアップは午前1時頃にスケジュールするのが理想的です。
ステップ 4: テストの実施 – 運任せにしない
復元テストを行わないバックアップは、バックアップを取っていないのと同じです。まずは手動でバックアップを実行し、速度と動作を確認しましょう。
veeamconfig job start --name "Daily_Full_Backup"
進捗状況は veeamconfig session list で確認できます。通常、100GBのサーバーであれば、社内LAN経由の初回バックアップは約15〜20分で完了します。
失敗しないための実戦経験アドバイス
Linux システムの運用で何度も修羅場をくぐり抜けてきた経験から、以下の3点に注意してください。
- リカバリメディアを今すぐ作成する: Veeam のリカバリ ISO ファイルをエクスポートし、クラウドや USB に保存しておいてください。このファイルがないと、OSが起動しなくなった際、バックアップデータはただのデータの塊になってしまいます。
- 容量の監視: Veeam は増分バックアップ(変更分のみ保存)を使用しますが、サーバーが大量のログを出力すると、バックアップ容量が急増します。ストレージを最適化するために、7〜14日程度の保持ポリシー(Retention Policy)を設定しましょう。
- ファイアウォールポートの開放: SMB/NFS プロトコル経由で NAS にバックアップする場合、
firewalldで関連するポートをallowするのを忘れないでください。接続エラーの解決に午後を丸々潰すのはもったいないです。
おわりに
CentOS Stream 9 に Veeam Agent を導入することは、心の平穏を得るための賢い投資です。トラブルの際にパッケージを一つずつ再インストールする代わりに、数回のクリックでシステムを自動復旧させることができます。重要なプロジェクトを管理しているなら、今日中にインストールしてください。「泥棒を見て縄をなう」ような事態になってからでは遅いのです。

