第11章: バックアップとリカバリ戦略

コンテンツ

11.1 この章で解説する主要な技術・概念
11.2 バックアップの基本方針
- 11.2.1 3-2-1ルール
- 11.2.2 バックアップの種類
11.3 手動バックアップと自動化
11.4 BaculaやAmandaなどの専用バックアップソフトウェア
- 11.4.1 Bacula
- 11.4.2 Amanda (Advanced Maryland Automatic Network Disk Archiver)
11.5 クラウドストレージ連携
- 11.5.1 rclone
- 11.5.2 S3互換ストレージ
11.6 ディザスタリカバリ (Disaster Recovery) 計画
11.7 バックアップの検証と定期テスト
11.8 学習のまとめ
- 次章へのつながり

11.1 この章で解説する主要な技術・概念

サーバー障害や災害のリスクを最小化するために、バックアップとリカバリの体制を整備することは不可欠です。AlmaLinux 9を含むLinuxサーバー運用では、複数の手法やツールを組み合わせて、データ喪失や長時間のサービス停止を防ぐ仕組みを構築します。本章では、以下のテーマを深掘りし、システムの安定稼働とビジネス継続性を高めるためのベストプラクティスを学びます。

バックアップの基本方針 (3-2-1ルールなど)
バックアップ方式 (フル, 増分, 差分) と運用例
手動バックアップ (rsync, tar) と自動化 (cron, systemd timers)
Bacula/Amanda などの専用バックアップソフトウェア
クラウドストレージ連携 (rclone, S3 など)
ディザスタリカバリ (Disaster Recovery) 計画
バックアップの検証と定期テスト

11.2 バックアップの基本方針

11.2.1 3-2-1ルール

3つのコピー: オリジナル + 2つのバックアップ
2種類の異なるメディア: 例）ローカルディスク + テープ、またはNAS + クラウド
1つはオフサイト保管: 建物火災や地震などに備え、遠隔地やクラウドにバックアップを置く

注: バックアップのうち1つが同じサーバー内だけの場合、ディスク障害などでオリジナルと同時に喪失する恐れがあるため危険。

11.2.2 バックアップの種類

フルバックアップ: データをすべて丸ごとバックアップ

復元が簡単だが、容量と時間が多くかかる

増分バックアップ: 前回のバックアップ以降に変更されたデータのみ

ストレージ節約が大きいが、復元時にはすべての増分を適用する必要がある

差分バックアップ: 最後のフルバックアップ以降に変更されたデータ

復元手順はフルバックアップ + 最新差分のみで済むが、増分よりも容量は多くなる

11.3 手動バックアップと自動化

11.3.1 rsyncを使ったバックアップ

rsync -av --delete /var/www/ /backup/var/www/

-a : アーカイブモード（パーミッションやタイムスタンプなどを保持）
-v : 詳細表示
--delete : ソースから削除されたファイルをバックアップ先でも削除（ミラーリング）

リモートバックアップ

rsync -av /var/www/ user@backup-server:/backup/www/

SSH経由で安全に転送
定期的に差分のみ転送するため、帯域と時間を節約

11.3.2 tarを使ったアーカイブと圧縮

tar -czf /backup/home_$(date +%Y%m%d).tar.gz /home

-c : アーカイブ作成
-z : gzip圧縮
-f : ファイル名指定
復元時は tar -xzf を用いて解凍・展開

ヒント:
ファイル数の多いディレクトリやメールボックスを一括して圧縮し、転送量を削減できる。ただし全体を展開しないと個別復元が難しい場合もある。

11.3.3 cron/systemd timersによる定期実行

crontab -e
# 毎日深夜3時にバックアップスクリプトを実行
0 3 * * * /usr/local/bin/backup_script.sh

または systemd timers を使用:

sudo systemctl enable backup_script.timer
sudo systemctl start backup_script.timer

タイマー単位で起動させることで、cronより柔軟なリソース制御やログイン依存のない実行を実現

11.4 BaculaやAmandaなどの専用バックアップソフトウェア

11.4.1 Bacula

Bacula
エンタープライズ向けのバックアップシステム。サーバー（Director）、ストレージデーモン、ファイルデーモン(クライアント)が連携するモデル。

構成要素

Director: バックアップジョブのスケジューリングと管理
Storage Daemon: バックアップ先（テープドライブやディスク）を管理
File Daemon: バックアップ対象ホストで動作し、ファイルの読み取り・転送を行う
Catalog: MySQLやPostgreSQLにメタデータを保存し、復元時に高速検索が可能

sudo dnf install bacula-director bacula-console bacula-storage bacula-client

/etc/bacula/ 配下でDirectorや各デーモンの設定ファイルを編集
BaculaはWeb管理コンソール(Bacula Webなど)でジョブ状況やスケジュールを可視化

11.4.2 Amanda (Advanced Maryland Automatic Network Disk Archiver)

Amanda
クライアント/サーバーモデルを採用し、ディスクやテープへのバックアップを自動スケジューリング。歴史が長く安定性も高い。

Amanda Server: スケジューリングとメタデータ管理
Amanda Client: 各ホストに導入してデータを送信
テープライブラリやディスクストレージを指定し、フル/増分/差分を自動管理

運用上のポイント

Amanda独自のamanda.confやdisklistで設定を行う
テープオペレーションをスクリプト化し、交換時期や書き込みエラーを監視

11.5 クラウドストレージ連携

11.5.1 rclone

rclone
多種多様なクラウドストレージ (AWS S3, Google Drive, Dropbox, etc.) と同期ができるCLIツール。

sudo dnf install rclone
rclone config     # インタラクティブにリモートを追加

# バックアップをS3に同期
rclone sync /backup s3:mybucket/backup --progress

copy, sync, move などのサブコマンド
--dry-run で試験実行

11.5.2 S3互換ストレージ

MinIOやWasabiなど、S3 API互換のクラウドストレージにも同様の方法でバックアップ可能
認証キーとシークレットキーの管理を安全に行う (例: ~/.rclone.conf, Vault, etc.)

11.6 ディザスタリカバリ (Disaster Recovery) 計画

11.6.1 RPOとRTOの設定

RPO (Recovery Point Objective)

どの時点までのデータを復旧するか。例: 最悪でも24時間前までのデータは保持したい

RTO (Recovery Time Objective)

どのくらいの時間で復旧できるか。例: サービス停止から2時間以内に復旧

ポイント: RPO/RTOを事前に明確化し、それに応じてバックアップ頻度やDRサイト構築を検討する。

11.6.2 DRサイトとフェイルオーバー

オンプレ + クラウド: 主要データをクラウドストレージにレプリケーションし、障害発生時にクラウド側で復旧
マルチデータセンター: 2拠点でサービスを同時稼働 or 片方スタンバイ
DBレプリケーション: MariaDBのGalera ClusterやPostgreSQLのストリーミングレプリケーションを活用し、別サイトでリアルタイム同期

11.6.3 定期リカバリテスト

バックアップが正しく復元できるかを確認するテストが欠かせない
仮想環境でテスト用マシンにリストアし、アプリケーションが動作することを確かめる
テープやクラウドからの戻し時間を計測し、RTOを満たすか検証

11.7 バックアップの検証と定期テスト

11.7.1 バックアップファイルの整合性チェック

MD5/SHA256ハッシュ: tarやrsyncの後にsha256sumでハッシュを作成し、改ざん防止
rsync --checksum : ファイル内容のチェックサムを使って差分を検出するが、負荷が高いので大容量では注意

11.7.2 スクリプトとログ管理

バックアップスクリプトでechoやloggerコマンドを使い、操作ログをsyslogへ送信
失敗時にメールやSlack通知を飛ばすなど、障害に素早く気付ける仕組みを導入

11.7.3 バックアップの世代管理

世代数: 直近3世代以上のフルバックアップを保持し、1ヶ月前や半年年前の状態に戻せるようにする
ローテーション: ストレージ容量と復元ニーズを鑑み、古いバックアップを定期的に削除

11.8 学習のまとめ

バックアップの基本方針: 3-2-1ルールを念頭に置き、複数のコピーとオフサイト保管で災害リスクを軽減。フル/増分/差分を使い分け、容量と復旧手順のバランスを取る。
手動バックアップ (rsync, tar): シンプルかつ柔軟。cronやsystemd timersでスケジュール化し、差分同期や圧縮アーカイブを駆使して運用。
Bacula/Amanda: エンタープライズ向けの集中管理型バックアップソリューション。ジョブスケジューリングやカタログ管理が充実しており、多数のサーバーを一元化できる。
クラウドストレージ連携: rcloneやS3互換APIを利用し、地理的に離れた場所へのバックアップで災害対策を強化。
ディザスタリカバリ (DR) 計画: RPO/RTOを明確にし、DRサイトやレプリケーションを活用。定期的なリカバリテストが現実的な復旧時間を把握する鍵となる。
検証と定期テスト: バックアップが正しく復旧できることを定期的に確認。ハッシュやログ管理を通じて改ざんや失敗を素早く察知。

次章へのつながり

次の章（第12章）では、AlmaLinux 9での自動化とスクリプト作成をさらに深堀りします。シェルスクリプトやAnsibleなどの構成管理ツールを使った運用自動化や大規模サーバーの一括管理手法を学び、作業効率と信頼性を高めるアプローチを習得していきましょう。