サーバー運用において、バックアップとリストアは最後の砦です。障害が発生したとき、バックアップがなければデータを失い、リストア手順が整備されていなければ復旧に何時間もかかります。本記事では、AlmaLinux 9 で使える tar・rsync・LVM スナップショットによるバックアップ手法から、定期自動化、世代管理、リストア検証、ベアメタルリストア（ReaR）まで、企業のサーバー運用チームが必要とする一連の手順を実行例つきでまとめています。シリーズ最終回として、これまでの回で構築した環境を守るためのバックアップ運用を体系的に整理しています。
コマンド早見表
| 目的 | コマンド |
|---|---|
| tar フルバックアップ | tar czf /tmp/etc-backup-YYYYMMDD.tar.gz /etc |
| tar 増分バックアップ | tar czf –listed-incremental=snapshot.file archive.tar.gz /対象 |
| tar リストア | tar xzpf archive.tar.gz -C /restore-dir |
| tar 内容一覧 | tar tzf archive.tar.gz |
| rsync ローカルコピー | rsync -av /etc/ /backup/etc/ |
| rsync リモート転送 | rsync -avz -e ssh /etc/ user@host:/backup/etc/ |
| rsync 事前確認 | rsync -avn –delete /src/ /dst/ |
| LVM スナップショット作成 | lvcreate -L 500M -s -n snap名 /dev/VG/LV |
| LVM スナップショット復元 | lvconvert –merge /dev/VG/snap名 |
| スナップショット状態確認 | lvs |
| パッケージ一覧保存 | rpm -qa –last > packages.txt |
| サービス一覧保存 | systemctl list-unit-files –state=enabled > services.txt |
| 古い世代の削除 | find /backup/daily -mtime +7 -name “*.tar.gz” -delete |
| SELinux コンテキスト修復 | restorecon -Rv /path |
| ReaR バックアップ作成 | rear mkbackup |
前提条件
| 項目 | 値 |
|---|---|
| OS | AlmaLinux 9.6（Sage Margay） |
| tar | GNU tar 1.34 |
| rsync | 3.2.5 |
| LVM | datavg VG（sdb + sdc、datalv 8GB） |
| ReaR | 2.6（appstream リポジトリ） |
| 転送先サーバー | alma-sub（192.168.1.122） |
| バックアップサーバー | backup.example.corp |
| 実行ユーザー | root 権限 |
1. バックアップの基礎知識
バックアップを計画する前に、バックアップの種類と復旧に関する指標を理解しておく必要があります。ここでは、実務で使われる 3 つのバックアップ方式と、復旧要件を定義する RPO・RTO の概念を説明します。
フル・差分・増分の 3 分類
| 方式 | バックアップ対象 | リストア時に必要なデータ | バックアップ時間 | ストレージ消費 |
|---|---|---|---|---|
| フルバックアップ | 全データ | 最新のフルバックアップ 1 つ | 長い | 大きい |
| 差分バックアップ | 前回フルからの変更分 | フル + 最新の差分 | 中程度 | 中程度 |
| 増分バックアップ | 前回バックアップからの変更分 | フル + すべての増分（順番に） | 短い | 小さい |
フルバックアップはリストアが単純ですが、毎回全データをコピーするため時間とストレージを消費します。増分バックアップは効率的ですが、リストア時にフルバックアップからすべての増分を順番に適用する必要があるため、手順が複雑になります。企業では「週次フル + 日次増分」の組み合わせがよく使われます。
RPO と RTO
RPO（Recovery Point Objective）は「どの時点までデータを戻せるか」を定義する指標です。日次バックアップであれば RPO は最大 24 時間となり、障害発生時に最大 24 時間分のデータを失う可能性があります。RTO（Recovery Time Objective）は「障害発生から何時間以内に復旧するか」を定義する指標です。バックアップ方式とリストア手順の整備状況によって RTO は大きく変わります。
RPO と RTO は事業部門と合意して決めるものであり、インフラチームが独断で決めるものではありません。ただし、「RPO を短くするほどバックアップの頻度とコストが上がる」「RTO を短くするほどリストア手順の整備とテストが必要になる」というトレードオフを説明できるようにしておく必要があります。
3-2-1 ルール
バックアップの保管方針として広く採用されているのが 3-2-1 ルールです。
- 3：データのコピーを 3 つ持つ（本番データ + バックアップ 2 つ）
- 2：2 種類以上の異なるメディアに保存する（ローカルディスク + テープ / NAS / クラウドなど）
- 1：1 つはオフサイト（物理的に離れた場所）に保管する
サーバーと同じディスクにバックアップを置いただけでは、ディスク障害時にバックアップごと失われます。最低限、別サーバーへの転送を行い、可能であれば別拠点やクラウドストレージへの保管を検討してください。
バックアップ対象の選定基準
| 対象 | 優先度 | 理由 |
|---|---|---|
| OS 設定（/etc） | 高 | 再構築時に必要。変更頻度は低いがフルバックアップ推奨 |
| ユーザーデータ（/home） | 高 | 業務データ。容量が大きいため増分バックアップが有効 |
| アプリケーションデータ（/var/lib） | 中〜高 | DB などサービスに依存。サービス停止を伴うことがある |
| ログ（/var/log） | 低 | ログ管理（第 10 回参照）で別途対応 |
| OS 本体（/usr, /bin 等） | 低 | パッケージマネージャで再インストール可能 |
2. tar によるバックアップ・リストア
tar は Linux で最も基本的なアーカイブツールです。単一のコマンドでディレクトリをまるごと圧縮・展開できるため、設定ファイルのバックアップに適しています。
フルバックアップ
/etc ディレクトリ全体を gzip 圧縮してアーカイブします。設定変更の前後でこのコマンドを実行しておくと、問題発生時に差し替えで戻せます。
実行コマンド：
# tar czf /tmp/etc-backup-20260326.tar.gz /etc実行結果（ファイルサイズの確認）：
# ls -lh /tmp/etc-backup-20260326.tar.gz
-rw-r--r--. 1 root root 4.7M 3月 26 08:12 /tmp/etc-backup-20260326.tar.gz各オプションの意味は次の通りです。c はアーカイブ作成、z は gzip 圧縮、f は出力ファイル名の指定です。
除外指定
システム全体をバックアップする場合、仮想ファイルシステムを除外する必要があります。/proc、/sys、/dev はカーネルが動的に生成するため、バックアップ対象に含めると不要なデータが増え、リストア時に問題を引き起こします。
実行コマンド：
# tar czf /tmp/system-backup-20260326.tar.gz --exclude=/proc --exclude=/sys --exclude=/dev --exclude=/tmp --exclude=/run /増分バックアップ
--listed-incremental オプションを使うと、前回からの変更分だけをアーカイブできます。スナップショットファイルに前回のバックアップ時点の情報が記録され、次回実行時に差分だけを抽出します。
実行コマンド（初回＝フルバックアップ）：
# tar czf /backup/etc-full-20260326.tar.gz --listed-incremental=/backup/etc-snapshot.snar /etc実行コマンド（2 回目以降＝増分バックアップ）：
# tar czf /backup/etc-inc-20260327.tar.gz --listed-incremental=/backup/etc-snapshot.snar /etc初回実行時にスナップショットファイルが存在しない場合はフルバックアップになります。2 回目以降は前回のスナップショットファイルと比較して変更されたファイルだけがアーカイブに含まれます。
増分バックアップのリストア順序
増分バックアップからリストアする場合は、フルバックアップを先にリストアし、その後に増分バックアップを取得日時順に 1 つずつリストアする必要があります。途中の増分を飛ばすとデータの整合性が崩れます。
リストア
アーカイブを指定したディレクトリに展開します。-p オプションでパーミッション（所有者・権限）を保持したままリストアします。本番環境に直接上書きする前に、別ディレクトリに展開して内容を確認する運用を推奨します。
実行コマンド：
# tar xzpf /tmp/etc-backup-20260326.tar.gz -C /restore-dir各オプションの意味は次の通りです。x は展開、z は gzip 解凍、p はパーミッション保持、f はファイル名の指定、-C は展開先ディレクトリの指定です。
アーカイブ検証
バックアップ取得後は、アーカイブの内容を確認して正常に取得できたことを検証します。
実行コマンド（内容一覧の確認）：
# tar tzf /tmp/etc-backup-20260326.tar.gz | head実行結果：
etc/
etc/mtab
etc/fstab
etc/crypttab
etc/lvm/
etc/lvm/devices/t オプションでアーカイブ内のファイル一覧を表示できます。ファイルが含まれていることを確認してください。
実行コマンド（整合性チェック）：
# md5sum /tmp/etc-backup-20260326.tar.gzmd5sum の出力値を記録しておき、転送後に転送先でも同じコマンドを実行して値が一致することを確認します。不一致であればファイルが破損しています。
3. rsync によるバックアップ・同期
rsync はファイルの差分転送に対応した同期ツールです。変更のあったファイルだけを転送するため、2 回目以降の転送が高速です。ローカルコピーにもリモートサーバーへの転送にも使えます。
ローカルコピー
同一サーバー内の別ディレクトリにバックアップを取る場合の基本コマンドです。
実行コマンド：
# rsync -av /etc/ /backup/etc/-a はアーカイブモード（パーミッション・所有者・タイムスタンプを保持して再帰的にコピー）、-v は転送内容の詳細表示です。末尾のスラッシュ（/etc/）はディレクトリの中身を転送することを意味します。スラッシュを付けない場合（/etc）は、ディレクトリ自体がコピーされ /backup/etc/etc/ という構造になるため注意してください。
リモート転送
SSH 経由で別サーバーにバックアップを転送します。SSH設定編で設定した鍵認証を使うことで、パスワード入力なしで自動転送が可能になります。
実行コマンド：
# rsync -avz -e ssh /etc/ developer@192.168.1.122:/backup/etc/実行結果：
sent 5,161 bytes received 117 bytes 10,556.00 bytes/sec
total size is 589,237 speedup is 111.64-z は転送時にデータを圧縮するオプションです。speedup is 111.64 は、差分転送により実際の転送量が全体の約 1/112 で済んだことを示しています。
差分転送の仕組み
rsync はファイルのサイズとタイムスタンプを比較し、変更があったファイルだけを転送します。--checksum オプションを付けると、チェックサム（MD5）で比較するため、より正確に差分を検出できます。ただしチェックサム計算に CPU を使うため、ファイル数が多い環境ではバックアップ時間が伸びる可能性があります。
–delete（ミラーリング）
–delete はファイルを削除するオプション
--delete を付けると、転送元に存在しないファイルが転送先から削除されます。転送元のパスを間違えた場合（例: 空のディレクトリを指定した場合）、転送先のファイルがすべて消失します。必ず --dry-run で事前確認してから実行してください。
実行コマンド（事前確認）：
# rsync -avn --delete /etc/ /backup/etc/--dry-run（-n）を付けると、実際にはファイルを転送・削除せず、何が行われるかだけを表示します。出力内容を確認して問題がなければ、-n を外して実行します。
–exclude と –bwlimit
不要なファイルを除外する場合は --exclude、帯域を制限する場合は --bwlimit を使います。企業ネットワークでは、バックアップの転送が他の業務通信に影響を与えないように帯域制限を設定することが一般的です。
実行コマンド：
# rsync -avz --exclude='*.tmp' --exclude='cache/' --bwlimit=10000 -e ssh /data/ developer@192.168.1.122:/backup/data/--bwlimit=10000 は転送速度を 10,000 kB/s（約 10 MB/s）に制限します。値はネットワーク環境に応じて調整してください。
4. LVM スナップショットの活用
LVM スナップショットは、論理ボリュームのある時点の状態を瞬時に保存する機能です。ストレージ・LVM編で構築した datavg / datalv を使って操作します。
スナップショットの仕組み（CoW）
LVM スナップショットは CoW（Copy-on-Write）方式で動作します。スナップショットを作成した時点ではデータのコピーは行われず、元のボリュームでデータが変更されたときに、変更前のデータだけをスナップショット領域にコピーします。このため、スナップショットの作成は瞬時に完了し、消費するディスク容量は変更されたデータの分だけです。
スナップショットの作成
設定変更やアップデートの前にスナップショットを作成しておくと、問題発生時に変更前の状態に戻せます。
実行コマンド：
# lvcreate -L 500M -s -n datalv-snap /dev/datavg/datalv-L 500M はスナップショット領域のサイズ、-s はスナップショット作成、-n はスナップショット名の指定です。スナップショット領域のサイズは、元のボリュームで変更が見込まれるデータ量を基に決めます。
実行コマンド（状態確認）：
# lvs実行結果：
LV VG Attr LSize Pool Origin Data%
datalv datavg owi-aos--- 8.00g
datalv-snap datavg swi-a-s--- 500.00m datalv 0.00Data% が 0.00 であることから、スナップショット作成直後でまだ変更データがコピーされていない状態です。この値が 100% に達するとスナップショットが無効化されます。
スナップショットの内容確認
スナップショットを読み取り専用でマウントして、中身を確認できます。
実行コマンド：
# mount -o ro /dev/datavg/datalv-snap /mnt/snap確認が終わったらアンマウントします。
実行コマンド：
# umount /mnt/snapスナップショットからの復元
lvconvert --merge でスナップショットを元のボリュームにマージし、スナップショット作成時点の状態に戻します。マージ前に元のボリュームをアンマウントする必要があります。
実行コマンド：
# umount /dev/datavg/datalv
# lvconvert --merge /dev/datavg/datalv-snap切り戻し方法：マージ操作自体を元に戻すことはできません。マージ前に別途バックアップを取得しておくか、マージを実行する前にスナップショットの内容をマウントして確認してください。
スナップショットはバックアップの代替にならない
LVM スナップショットは元のボリュームと同じ物理ディスク上に作成されます。ディスク障害が発生した場合、スナップショットも同時に失われます。スナップショットは「作業前の一時的な保険」として使い、長期保存のバックアップは別サーバーや別メディアに取得してください。
スナップショット領域の監視
lvs コマンドの Data% 列を定期的に確認し、スナップショット領域の使用率を監視します。80% を超えたら、スナップショットの削除（lvremove）またはスナップショット領域の拡張を検討してください。
実行コマンド（スナップショット削除）：
# lvremove /dev/datavg/datalv-snap5. 設定ファイルのバックアップ戦略
サーバーを再構築する際に必要な設定情報は、ファイルシステムだけでなくコマンドの出力にも含まれます。ここでは、OS 再構築時に必要な情報を網羅的にバックアップする方法を説明します。
バックアップ対象の一覧
| 対象 | バックアップ方法 | 復元時の用途 |
|---|---|---|
| /etc | tar フルバックアップ | 設定ファイルの復元 |
| /home | rsync 増分転送 | ユーザーデータの復元 |
| /var/lib | サービスに応じて判断 | DB データ等の復元 |
| パッケージ一覧 | rpm -qa –last | 同じパッケージの再インストール |
| サービス一覧 | systemctl list-unit-files –state=enabled | 有効化すべきサービスの確認 |
| firewalld 設定 | firewall-cmd –list-all | ファイアウォールルールの再設定 |
| crontab | crontab -l | 定期実行タスクの復元 |
パッケージ一覧の保存
インストール済みパッケージの一覧を保存しておくと、再構築時に同じパッケージをインストールできます。
実行コマンド：
# rpm -qa --last > /backup/packages-20260326.txt--last オプションはインストール日時順に表示します。最近インストールしたパッケージが先頭に来るため、何を追加したかの確認にも使えます。
サービス一覧の保存
実行コマンド：
# systemctl list-unit-files --state=enabled > /backup/services-20260326.txtfirewalld 設定の保存
実行コマンド：
# firewall-cmd --list-all > /backup/firewalld-config-20260326.txtcrontab の保存
実行コマンド：
# crontab -l > /backup/crontab-backup-20260326.txt復元時は crontab /backup/crontab-backup-20260326.txt でインポートできます。
6. 定期バックアップの自動化
手動でバックアップを取得する運用は、担当者の失念や休暇によりバックアップが欠損するリスクがあります。cron または systemd timer（cron / systemd timer 編参照）で自動化します。
バックアップスクリプトの実装例
日付付きファイル名で /etc のバックアップを取得し、ログを記録するスクリプトです。異常時には logger コマンドで syslog にエラーを記録します。
#!/bin/bash
BACKUP_DIR="/backup/daily"
DATE=$(date +%Y%m%d)
LOG="/var/log/backup.log"
mkdir -p "${BACKUP_DIR}"
echo "$(date '+%Y-%m-%d %H:%M:%S') Backup started" >> "${LOG}"
tar czf "${BACKUP_DIR}/etc-backup-${DATE}.tar.gz" /etc >> "${LOG}" 2>&1
if [ $? -eq 0 ]; then
echo "$(date '+%Y-%m-%d %H:%M:%S') Backup completed successfully" >> "${LOG}"
else
echo "$(date '+%Y-%m-%d %H:%M:%S') Backup FAILED" >> "${LOG}"
logger -p local0.err "Backup failed: etc-backup-${DATE}.tar.gz"
fiスクリプトを /usr/local/bin/backup-etc.sh として保存し、実行権限を付与します。
実行コマンド：
# chmod 700 /usr/local/bin/backup-etc.sh権限を 700（root のみ実行可能）にするのは、バックアップスクリプトの内容にサーバー構成情報が含まれる場合があるためです。
cron での設定例
毎日 2:00 にバックアップを実行する設定です。
実行コマンド：
# crontab -e追加する行：
0 2 * * * /usr/local/bin/backup-etc.shsystemd timer での設定例
systemd timer を使う場合は、.service ファイルと .timer ファイルのペアを作成します。
/etc/systemd/system/backup-etc.service：
[Unit]
Description=Daily etc backup
[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-etc.sh/etc/systemd/system/backup-etc.timer：
[Unit]
Description=Daily etc backup timer
[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
[Install]
WantedBy=timers.targetPersistent=true を設定すると、サーバーが停止していて実行時刻を逃した場合に、次回起動時に実行されます。
実行コマンド（timer の有効化）：
# systemctl daemon-reload
# systemctl enable --now backup-etc.timer切り戻し方法：timer を無効化する場合は systemctl disable --now backup-etc.timer を実行します。
7. 社内バックアップサーバーへの転送
ローカルにバックアップを取るだけでは、サーバー自体の障害やディスク故障でバックアップも失われます。社内バックアップサーバー（backup.example.corp）に SSH 経由で転送する手順を説明します。
転送先ディレクトリ設計
バックアップサーバー側のディレクトリは、ホスト名と日付で構造化します。複数サーバーのバックアップを管理する場合に、どのサーバーのいつのバックアップかを特定しやすくなります。
/backup/
├── alma-main/
│ ├── 20260324/
│ ├── 20260325/
│ └── 20260326/
└── alma-sub/
├── 20260324/
└── 20260325/rsync over SSH の自動転送スクリプト
SSH 鍵認証（SSH設定編参照）が設定済みであることが前提です。
#!/bin/bash
REMOTE_HOST="backup.example.corp"
REMOTE_USER="backupuser"
REMOTE_DIR="/backup/$(hostname)/$(date +%Y%m%d)"
LOCAL_DIR="/backup/daily/"
LOG="/var/log/backup-transfer.log"
MAX_RETRY=3
RETRY_COUNT=0
echo "$(date '+%Y-%m-%d %H:%M:%S') Transfer started" >> "${LOG}"
ssh "${REMOTE_USER}@${REMOTE_HOST}" "mkdir -p ${REMOTE_DIR}"
while [ ${RETRY_COUNT} -lt ${MAX_RETRY} ]; do
rsync -avz --checksum -e ssh "${LOCAL_DIR}" "${REMOTE_USER}@${REMOTE_HOST}:${REMOTE_DIR}/" >> "${LOG}" 2>&1
if [ $? -eq 0 ]; then
echo "$(date '+%Y-%m-%d %H:%M:%S') Transfer completed successfully" >> "${LOG}"
exit 0
fi
RETRY_COUNT=$((RETRY_COUNT + 1))
echo "$(date '+%Y-%m-%d %H:%M:%S') Transfer failed (attempt ${RETRY_COUNT}/${MAX_RETRY})" >> "${LOG}"
sleep 60
done
echo "$(date '+%Y-%m-%d %H:%M:%S') Transfer FAILED after ${MAX_RETRY} attempts" >> "${LOG}"
logger -p local0.err "Backup transfer to ${REMOTE_HOST} failed after ${MAX_RETRY} attempts"
exit 1スクリプトのポイントは次の通りです。--checksum で転送後の整合性を確認しています。転送失敗時は 60 秒間隔で最大 3 回リトライし、すべて失敗した場合は logger でエラーを syslog に記録します。
8. 世代管理
バックアップを取り続けるとストレージを圧迫するため、古い世代を自動で削除する仕組みが必要です。日次・週次・月次で保持世代数を分けることで、直近の復旧と過去の特定時点への復旧の両方に対応します。
ローテーション方針
| 種別 | 頻度 | 保持世代数 | 保持期間 |
|---|---|---|---|
| 日次 | 毎日 | 7 世代 | 過去 7 日分 |
| 週次 | 毎週日曜 | 4 世代 | 過去 4 週分 |
| 月次 | 毎月 1 日 | 3 世代 | 過去 3 か月分 |
ディレクトリ構成例
/backup/
├── daily/
│ ├── etc-backup-20260320.tar.gz
│ ├── etc-backup-20260321.tar.gz
│ ...
│ └── etc-backup-20260326.tar.gz
├── weekly/
│ ├── etc-backup-20260308.tar.gz
│ ├── etc-backup-20260315.tar.gz
│ └── etc-backup-20260322.tar.gz
└── monthly/
├── etc-backup-20260101.tar.gz
├── etc-backup-20260201.tar.gz
└── etc-backup-20260301.tar.gz古い世代の自動削除
find コマンドの -mtime オプションで、指定日数以上前のファイルを削除します。
実行コマンド（日次バックアップの 7 日超過分を削除）：
# find /backup/daily -name "*.tar.gz" -mtime +7 -delete実行コマンド（週次バックアップの 28 日超過分を削除）：
# find /backup/weekly -name "*.tar.gz" -mtime +28 -delete実行コマンド（月次バックアップの 90 日超過分を削除）：
# find /backup/monthly -name "*.tar.gz" -mtime +90 -deleteこれらのコマンドをバックアップスクリプトの末尾に追加するか、別の cron ジョブとして設定します。
logrotate との違い
logrotate はログファイルのローテーションを行うツールであり、バックアップファイルの世代管理とは目的が異なります。バックアップファイルの世代管理には find コマンドやスクリプトで独自に実装してください。logrotate でバックアップファイルを管理しようとすると、圧縮形式やファイル名の規則が合わず意図しない動作になる場合があります。
9. リストア検証の実践
バックアップは取得するだけでは意味がありません。リストアが正常に完了し、サービスが復旧することを確認して初めてバックアップの価値が証明されます。年に 1 回以上はリストアテストを実施することを推奨します。
リストアテストの重要性
リストアテストを実施しないまま本番障害が発生した場合に起こりうる問題の例です。
- バックアップファイルが破損していた（アーカイブのヘッダ異常、ディスクエラー）
- バックアップ対象に必要なファイルが含まれていなかった
- リストア手順が文書化されておらず、復旧に時間がかかった
- リストア後にサービスが起動しなかった（設定の依存関係の問題）
リストア手順書テンプレート
| 手順 | 内容 | コマンド例 |
|---|---|---|
| 1 | バックアップファイルの所在確認 | ls -lh /backup/daily/ |
| 2 | アーカイブの整合性確認 | tar tzf archive.tar.gz > /dev/null |
| 3 | リストア先ディレクトリの作成 | mkdir -p /restore-dir |
| 4 | リストアの実行 | tar xzpf archive.tar.gz -C /restore-dir |
| 5 | ファイルの確認（差分比較） | diff -r /restore-dir/etc /etc |
| 6 | 必要なファイルを本番パスにコピー | cp -a /restore-dir/etc/httpd/ /etc/httpd/ |
| 7 | SELinux コンテキストの修復 | restorecon -Rv /etc/httpd/ |
| 8 | サービスの再起動 | systemctl restart httpd |
| 9 | サービスの動作確認 | systemctl status httpd / curl localhost |
| 10 | ログの確認 | journalctl -u httpd –since “5 min ago” |
リストア後の確認項目
- サービス起動：systemctl status で対象サービスが active (running) であること
- データ整合性：アプリケーションからデータを参照し、期待通りの値が返ること
- ログ確認：journalctl でエラーが出ていないこと
- SELinux コンテキスト：restorecon -Rv でコンテキストを修復する。tar で展開したファイルは SELinux のラベルが正しく設定されていない場合がある
実行コマンド（SELinux コンテキストの修復）：
# restorecon -Rv /etc-R は再帰的に処理、-v は変更内容を表示するオプションです。
10. 物理サーバーのベアメタルリストア（ReaR）
仮想サーバーでは通常 ReaR は不要
仮想サーバー（KVM、VMware、Hyper-V など）ではハイパーバイザーのスナップショットやテンプレート機能で OS ごと復元できるため、ReaR によるベアメタルリストアは通常不要です。ReaR は物理サーバーの復旧に使用するツールです。
ReaR（Relax-and-Recover）の概要
ReaR は RHEL 9 で公式にサポートされているベアメタルリストアツールです。復旧用の ISO イメージとバックアップデータを作成し、ハードウェア障害時に OS ごと復旧できます。「ベアメタルリストア」とは、OS が入っていない空のサーバー（ベアメタル＝裸の金属）に対して、OS・設定・データをまとめて復元する手法です。
ReaR のインストール
実行コマンド：
# dnf install -y rearappstream リポジトリから ReaR 2.6 がインストールされます。
設定ファイル（/etc/rear/local.conf）
NFS サーバーにバックアップを保存する設定例です。
OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL=nfs://backup.example.corp/backup/rear/
OUTPUT_URL=nfs://backup.example.corp/backup/rear/OUTPUT=ISO は復旧用 ISO イメージを作成する設定、BACKUP=NETFS は tar を使ったバックアップ方式、BACKUP_URL はバックアップデータの保存先です。
バックアップの実行
実行コマンド：
# rear mkbackupこのコマンドにより、復旧用 ISO イメージとバックアップアーカイブが作成されます。ISO イメージには、リストアに必要なカーネル、ドライバ、リストアスクリプトが含まれています。
リストアの流れ
- 復旧用 ISO で対象サーバーを起動する
rear recoverコマンドを実行する- ディスクのパーティション構成が自動で再構築される
- バックアップデータがリストアされる
- ブートローダーが再インストールされる
- サーバーを再起動して復旧を確認する
制約事項
- UEFI / Secure Boot：ReaR は UEFI 環境に対応していますが、Secure Boot が有効な場合は一時的に無効化が必要な場合があります
- ハードウェア差異：元のサーバーと異なるハードウェアにリストアする場合、ストレージコントローラやネットワークドライバの違いにより追加設定が必要になることがあります
- 検証環境：物理サーバーがない環境では、ここまでの概要を把握しておき、物理サーバーが用意できた時点で実機検証を行ってください
11. 仮想サーバーのスナップショット活用
物理サーバーではハイパーバイザースナップショットは利用できない
物理サーバーではハイパーバイザーが存在しないため、ここで説明するハイパーバイザースナップショットは利用できません。物理サーバーで利用可能なスナップショットは、第 4 章で説明した LVM スナップショットのみです。
ハイパーバイザースナップショットと LVM スナップショットの違い
| 項目 | ハイパーバイザースナップショット | LVM スナップショット |
|---|---|---|
| 対象範囲 | 仮想マシン全体（ディスク + メモリ + CPU 状態） | 論理ボリューム単位 |
| 利用可能環境 | 仮想サーバーのみ | 物理・仮想どちらでも |
| 操作方法 | ハイパーバイザーの管理画面 / CLI | lvcreate / lvconvert コマンド |
| 取得速度 | 数秒〜数十秒 | 数秒 |
| 障害耐性 | ホストサーバーの障害には無力 | 同一ディスクの障害には無力 |
KVM / libvirt のスナップショット（概要）
KVM 環境では virsh snapshot-create-as コマンドで仮想マシンのスナップショットを作成できます。OS のアップデートやカーネル更新の前に取得しておくと、問題発生時に数分で元の状態に戻せます。
VMware / Hyper-V のスナップショット（概要）
VMware vSphere では vSphere Client からスナップショットを作成・管理します。Hyper-V ではチェックポイント機能がスナップショットに相当します。いずれも管理画面から数クリックで取得でき、復元も同様に操作できます。
スナップショット長期保持の問題
スナップショットの長期保持は禁物
スナップショットを長期間保持すると、差分データが蓄積されてディスク I/O のパフォーマンスが低下します。また、スナップショットのチェーンが肥大化し、削除（統合）に長時間かかるようになります。スナップショットは作業前の一時的な保険として使い、作業完了後は速やかに削除してください。
併用戦略
| 用途 | 手法 | 保持期間 |
|---|---|---|
| 作業前の保険 | スナップショット（LVM / ハイパーバイザー） | 作業完了まで（数時間〜1 日） |
| 日常の復旧ポイント | tar / rsync による定期バックアップ | 日次 7 世代、週次 4 世代、月次 3 世代 |
| 災害対策 | オフサイトへの転送（バックアップサーバー） | 月次 3〜12 世代 |
12. バックアップ運用チェックリスト
バックアップ運用の全体を以下のチェックリストで総括します。各項目について、自分の担当サーバーで対応状況を確認してください。
| 分類 | 確認項目 | 関連する章 / 記事 |
|---|---|---|
| 対象選定 | バックアップ対象（/etc、/home、/var/lib 等）が明確に定義されている | 第 1 章・第 5 章 |
| 対象選定 | パッケージ一覧・サービス一覧・firewalld 設定・crontab がバックアップされている | 第 5 章 |
| 取得方法 | tar / rsync によるバックアップが設定されている | 第 2 章・第 3 章 |
| 自動化 | cron または systemd timer で定期実行が設定されている | 第 6 章・cron / systemd timer 編 |
| 転送 | 別サーバーへバックアップが転送されている（3-2-1 ルール） | 第 7 章 |
| 世代管理 | 日次・週次・月次のローテーションが設定されている | 第 8 章 |
| リストア | リストア手順書が作成・更新されている | 第 9 章 |
| リストア | 年 1 回以上のリストアテストが実施されている | 第 9 章 |
| 監視 | バックアップの成否をログで確認する仕組みがある | 第 6 章・ログ管理編 |
| スナップショット | LVM / ハイパーバイザースナップショットの用途と限界を理解している | 第 4 章・第 11 章・ストレージ・LVM編 |
トラブルシューティング
tar リストアでパーミッションが変わった
tar でリストアした際にファイルの所有者やパーミッションが変わってしまう場合、-p オプションが指定されていない可能性があります。-p はパーミッション保持オプションで、アーカイブに記録された所有者・権限をそのまま復元します。また、リストアは root 権限で実行する必要があります。一般ユーザーで実行すると、root 所有のファイルが一般ユーザーの所有に変わります。
実行コマンド（正しいリストア方法）：
# tar xzpf /backup/daily/etc-backup-20260326.tar.gz -C /restore-dirrsync で –delete を使ったらファイルが全消失した
--delete オプションは転送元に存在しないファイルを転送先から削除します。転送元のパスを誤って空のディレクトリを指定した場合、転送先のすべてのファイルが削除されます。--delete を使う前には必ず --dry-run（-n）で事前確認する運用を徹底してください。
実行コマンド（事前確認）：
# rsync -avn --delete /etc/ /backup/etc/出力に deleting と表示されるファイルが想定通りであることを確認してから、-n を外して実行します。
LVM スナップショットが無効化された
スナップショット領域の使用率（Data%）が 100% に達すると、スナップショットは自動的に無効化され、復元に使えなくなります。lvs コマンドで定期的に Data% を監視してください。
実行コマンド：
# lvs80% を超えたら、スナップショットの削除（lvremove）を検討してください。スナップショットを長期間保持するほど領域不足のリスクが高まるため、作業完了後は速やかに削除する運用を推奨します。
rsync リモート転送で “Permission denied”
rsync のリモート転送で “Permission denied” が発生する原因は主に 2 つです。
- SSH 鍵認証が未設定：SSH設定編を参照して、公開鍵を転送先サーバーに登録してください
- 転送先ディレクトリの書き込み権限がない：転送先サーバーで、バックアップ用ユーザーが書き込めるディレクトリを用意してください
実行コマンド（転送先での権限設定）：
# chown backupuser:backupuser /backup
# chmod 750 /backupリストア後に SELinux のコンテキストエラーが発生
tar で展開したファイルや rsync で転送したファイルは、SELinux のセキュリティコンテキストが正しく設定されていない場合があります。サービスが “Permission denied” や “AVC denied” で起動しない場合は、restorecon でコンテキストを修復してください。
実行コマンド：
# restorecon -Rv /etc修復されたファイルが表示されます。特定のディレクトリに限定する場合は、パスを絞って実行してください。
