AlmaLinux 9 バックアップ・リストア

サーバー運用において、バックアップとリストアは最後の砦です。障害が発生したとき、バックアップがなければデータを失い、リストア手順が整備されていなければ復旧に何時間もかかります。本記事では、AlmaLinux 9 で使える tar・rsync・LVM スナップショットによるバックアップ手法から、定期自動化、世代管理、リストア検証、ベアメタルリストア（ReaR）まで、企業のサーバー運用チームが必要とする一連の手順を実行例つきでまとめています。シリーズ最終回として、これまでの回で構築した環境を守るためのバックアップ運用を体系的に整理しています。

目次

1. コマンド早見表
2. 前提条件
3. 1. バックアップの基礎知識
   1. フル・差分・増分の 3 分類
   2. RPO と RTO
   3. 3-2-1 ルール
   4. バックアップ対象の選定基準
4. 2. tar によるバックアップ・リストア
   1. フルバックアップ
   2. 除外指定
   3. 増分バックアップ
   4. リストア
   5. アーカイブ検証
5. 3. rsync によるバックアップ・同期
   1. ローカルコピー
   2. リモート転送
   3. 差分転送の仕組み
   4. –delete（ミラーリング）
   5. –exclude と –bwlimit
6. 4. LVM スナップショットの活用
   1. スナップショットの仕組み（CoW）
   2. スナップショットの作成
   3. スナップショットの内容確認
   4. スナップショットからの復元
   5. スナップショット領域の監視
7. 5. 設定ファイルのバックアップ戦略
   1. バックアップ対象の一覧
   2. パッケージ一覧の保存
   3. サービス一覧の保存
   4. firewalld 設定の保存
   5. crontab の保存
8. 6. 定期バックアップの自動化
   1. バックアップスクリプトの実装例
   2. cron での設定例
   3. systemd timer での設定例
9. 7. 社内バックアップサーバーへの転送
   1. 転送先ディレクトリ設計
   2. rsync over SSH の自動転送スクリプト
10. 8. 世代管理
    1. ローテーション方針
    2. ディレクトリ構成例
    3. 古い世代の自動削除
11. 9. リストア検証の実践
    1. リストアテストの重要性
    2. リストア手順書テンプレート
    3. リストア後の確認項目
12. 10. 物理サーバーのベアメタルリストア（ReaR）
    1. ReaR（Relax-and-Recover）の概要
    2. ReaR のインストール
    3. 設定ファイル（/etc/rear/local.conf）
    4. バックアップの実行
    5. リストアの流れ
    6. 制約事項
13. 11. 仮想サーバーのスナップショット活用
    1. ハイパーバイザースナップショットと LVM スナップショットの違い
    2. KVM / libvirt のスナップショット（概要）
    3. VMware / Hyper-V のスナップショット（概要）
    4. スナップショット長期保持の問題
    5. 併用戦略
14. 12. バックアップ運用チェックリスト
15. トラブルシューティング
    1. tar リストアでパーミッションが変わった
    2. rsync で –delete を使ったらファイルが全消失した
    3. LVM スナップショットが無効化された
    4. rsync リモート転送で “Permission denied”
    5. リストア後に SELinux のコンテキストエラーが発生
16. AlmaLinux 9 総合リファレンスガイド シリーズ一覧

コマンド早見表#

前提条件#

1. バックアップの基礎知識#

バックアップを計画する前に、バックアップの種類と復旧に関する指標を理解しておく必要があります。ここでは、実務で使われる 3 つのバックアップ方式と、復旧要件を定義する RPO・RTO の概念を説明します。

フル・差分・増分の 3 分類#

フルバックアップはリストアが単純ですが、毎回全データをコピーするため時間とストレージを消費します。増分バックアップは効率的ですが、リストア時にフルバックアップからすべての増分を順番に適用する必要があるため、手順が複雑になります。企業では「週次フル + 日次増分」の組み合わせがよく使われます。

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 つはオフサイト（物理的に離れた場所）に保管する

サーバーと同じディスクにバックアップを置いただけでは、ディスク障害時にバックアップごと失われます。最低限、別サーバーへの転送を行い、可能であれば別拠点やクラウドストレージへの保管を検討してください。

バックアップ対象の選定基準#

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 回目以降は前回のスナップショットファイルと比較して変更されたファイルだけがアーカイブに含まれます。

リストア#

アーカイブを指定したディレクトリに展開します。-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.gz

md5sum の出力値を記録しておき、転送後に転送先でも同じコマンドを実行して値が一致することを確認します。不一致であればファイルが破損しています。

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（ミラーリング）#

実行コマンド（事前確認）：

# 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.00

Data% が 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

切り戻し方法：マージ操作自体を元に戻すことはできません。マージ前に別途バックアップを取得しておくか、マージを実行する前にスナップショットの内容をマウントして確認してください。

スナップショット領域の監視#

lvs コマンドの Data% 列を定期的に確認し、スナップショット領域の使用率を監視します。80% を超えたら、スナップショットの削除（lvremove）またはスナップショット領域の拡張を検討してください。

実行コマンド（スナップショット削除）：

# lvremove /dev/datavg/datalv-snap

5. 設定ファイルのバックアップ戦略#

サーバーを再構築する際に必要な設定情報は、ファイルシステムだけでなくコマンドの出力にも含まれます。ここでは、OS 再構築時に必要な情報を網羅的にバックアップする方法を説明します。

バックアップ対象の一覧#

パッケージ一覧の保存#

インストール済みパッケージの一覧を保存しておくと、再構築時に同じパッケージをインストールできます。

実行コマンド：

# rpm -qa --last > /backup/packages-20260326.txt

--last オプションはインストール日時順に表示します。最近インストールしたパッケージが先頭に来るため、何を追加したかの確認にも使えます。

サービス一覧の保存#

実行コマンド：

# systemctl list-unit-files --state=enabled > /backup/services-20260326.txt

firewalld 設定の保存#

実行コマンド：

# firewall-cmd --list-all > /backup/firewalld-config-20260326.txt

crontab の保存#

実行コマンド：

# 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.sh

systemd 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.target

Persistent=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. 世代管理#

バックアップを取り続けるとストレージを圧迫するため、古い世代を自動で削除する仕組みが必要です。日次・週次・月次で保持世代数を分けることで、直近の復旧と過去の特定時点への復旧の両方に対応します。

ローテーション方針#

ディレクトリ構成例#

/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 ジョブとして設定します。

9. リストア検証の実践#

バックアップは取得するだけでは意味がありません。リストアが正常に完了し、サービスが復旧することを確認して初めてバックアップの価値が証明されます。年に 1 回以上はリストアテストを実施することを推奨します。

リストアテストの重要性#

リストアテストを実施しないまま本番障害が発生した場合に起こりうる問題の例です。

• バックアップファイルが破損していた（アーカイブのヘッダ異常、ディスクエラー）
• バックアップ対象に必要なファイルが含まれていなかった
• リストア手順が文書化されておらず、復旧に時間がかかった
• リストア後にサービスが起動しなかった（設定の依存関係の問題）

リストア手順書テンプレート#

リストア後の確認項目#

• サービス起動：systemctl status で対象サービスが active (running) であること
• データ整合性：アプリケーションからデータを参照し、期待通りの値が返ること
• ログ確認：journalctl でエラーが出ていないこと
• SELinux コンテキスト：restorecon -Rv でコンテキストを修復する。tar で展開したファイルは SELinux のラベルが正しく設定されていない場合がある

実行コマンド（SELinux コンテキストの修復）：

# restorecon -Rv /etc

-R は再帰的に処理、-v は変更内容を表示するオプションです。

10. 物理サーバーのベアメタルリストア（ReaR）#

ReaR（Relax-and-Recover）の概要#

ReaR は RHEL 9 で公式にサポートされているベアメタルリストアツールです。復旧用の ISO イメージとバックアップデータを作成し、ハードウェア障害時に OS ごと復旧できます。「ベアメタルリストア」とは、OS が入っていない空のサーバー（ベアメタル＝裸の金属）に対して、OS・設定・データをまとめて復元する手法です。

ReaR のインストール#

実行コマンド：

# dnf install -y rear

appstream リポジトリから 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 イメージには、リストアに必要なカーネル、ドライバ、リストアスクリプトが含まれています。

リストアの流れ#

1. 復旧用 ISO で対象サーバーを起動する
2. rear recover コマンドを実行する
3. ディスクのパーティション構成が自動で再構築される
4. バックアップデータがリストアされる
5. ブートローダーが再インストールされる
6. サーバーを再起動して復旧を確認する

制約事項#

• UEFI / Secure Boot：ReaR は UEFI 環境に対応していますが、Secure Boot が有効な場合は一時的に無効化が必要な場合があります
• ハードウェア差異：元のサーバーと異なるハードウェアにリストアする場合、ストレージコントローラやネットワークドライバの違いにより追加設定が必要になることがあります
• 検証環境：物理サーバーがない環境では、ここまでの概要を把握しておき、物理サーバーが用意できた時点で実機検証を行ってください

11. 仮想サーバーのスナップショット活用#

ハイパーバイザースナップショットと LVM スナップショットの違い#

KVM / libvirt のスナップショット（概要）#

KVM 環境では virsh snapshot-create-as コマンドで仮想マシンのスナップショットを作成できます。OS のアップデートやカーネル更新の前に取得しておくと、問題発生時に数分で元の状態に戻せます。

VMware / Hyper-V のスナップショット（概要）#

VMware vSphere では vSphere Client からスナップショットを作成・管理します。Hyper-V ではチェックポイント機能がスナップショットに相当します。いずれも管理画面から数クリックで取得でき、復元も同様に操作できます。

スナップショット長期保持の問題#

併用戦略#

12. バックアップ運用チェックリスト#

バックアップ運用の全体を以下のチェックリストで総括します。各項目について、自分の担当サーバーで対応状況を確認してください。

トラブルシューティング#

tar リストアでパーミッションが変わった#

tar でリストアした際にファイルの所有者やパーミッションが変わってしまう場合、-p オプションが指定されていない可能性があります。-p はパーミッション保持オプションで、アーカイブに記録された所有者・権限をそのまま復元します。また、リストアは root 権限で実行する必要があります。一般ユーザーで実行すると、root 所有のファイルが一般ユーザーの所有に変わります。

実行コマンド（正しいリストア方法）：

# tar xzpf /backup/daily/etc-backup-20260326.tar.gz -C /restore-dir

rsync で –delete を使ったらファイルが全消失した#

--delete オプションは転送元に存在しないファイルを転送先から削除します。転送元のパスを誤って空のディレクトリを指定した場合、転送先のすべてのファイルが削除されます。--delete を使う前には必ず --dry-run（-n）で事前確認する運用を徹底してください。

実行コマンド（事前確認）：

# rsync -avn --delete /etc/ /backup/etc/

出力に deleting と表示されるファイルが想定通りであることを確認してから、-n を外して実行します。

LVM スナップショットが無効化された#

スナップショット領域の使用率（Data%）が 100% に達すると、スナップショットは自動的に無効化され、復元に使えなくなります。lvs コマンドで定期的に Data% を監視してください。

実行コマンド：

# lvs

80% を超えたら、スナップショットの削除（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

修復されたファイルが表示されます。特定のディレクトリに限定する場合は、パスを絞って実行してください。

AlmaLinux 9 総合リファレンスガイド シリーズ一覧#

1. システム基本情報の確認
2. 初期設定
3. ネットワーク設定（nmcli）
4. パッケージ管理（dnf）
5. ユーザー・グループ管理
6. ファイアウォール（firewalld）
7. SSH設定・鍵認証
8. systemd / サービス管理
9. ストレージ・LVM
10. ログ管理（journalctl / rsyslog）
11. cron / systemd timer
12. セキュリティ強化
13. パフォーマンス監視
14. コンテナ管理（Podman）
15. バックアップ・リストア（この記事）