「サーバー自体」が壊れる日
こんにちは!「リナックス先生」です。
ついに最終回です。前回、Logrotateを設定してディスク容量不足の心配はなくなりました。これで完璧…だと思っていませんか?
▼これまでの連載(まだ読んでいない方はこちら!)
- 【第1回】設計編 – ログ管理の要件定義とプロトコル策定
- 【第2回】構築編 – インストールと「攻め」のセキュリティ設定
- 【第3回】設定編 – RainerScriptによるログ自動仕分け
- 【第4回】運用編 – Logrotateによる圧縮・世代管理
え?完璧じゃないんですか?
ログは整理されてるし、古いのは圧縮されるし、もうやる事ないですよ!
これ以上何を怖がればいいんですか?
コウ君、想像して。
もし明日、このログサーバーのSSDが物理的に故障して、起動しなくなったら?
中に溜め込んだ1年分の貴重なログは、すべて電子の藻屑よ。
1. 「3-2-1ルール」を知っていますか?
バックアップの世界には、有名な鉄則があります。
- 3: データを3つ持つ(本番データ + バックアップ2つ)。
- 2: 2種類の異なるメディアに保存する(SSDとHDD、またはサーバーとNASなど)。
- 1: 1つは物理的に離れた場所(オフサイト)に置く。
今回はこの「2」と「1」を満たすために、「NFS(ネットワーク越しのストレージ)」へデータを転送する仕組みを作ります。
2. NFSクライアントの設定と安全なマウント
まずは、AlmaLinuxからNAS(ファイルサーバー)のフォルダをマウントします。
パッケージ導入とマウントポイント作成
dnf install nfs-utils -y mkdir -p /mnt/log_backup
【重要】fstabによる自動マウント設定
サーバー再起動時にも自動で繋がるようにしますが、ここに罠があります。
ネットワークが起動する前にマウントしようとして起動失敗する事故を防ぐため、_netdev オプションが必須です。
vi /etc/fstab
▼追記内容(例:NAS IP 192.168.1.100)
192.168.1.100:/volume1/logs /mnt/log_backup nfs defaults,_netdev 0 0
追記後、mount -a コマンドを実行してエラーが出なければOKです。
3. プロ仕様のバックアップスクリプト作成
単なるコピー(cp)ではなく、rsync を使って「変更があった分だけ」を転送します。
さらに、失敗したら管理者にメールを飛ばす機能も付けましょう。
vi /usr/local/bin/backup_rsyslog.sh
スクリプト全文(コピペOK)
#!/bin/bash
# ==========================================
# Rsyslog Backup Script using rsync
# ==========================================
# ■設定エリア
SRC_DIR="/var/log/remote/" # 元データ
DEST_DIR="/mnt/log_backup/" # バックアップ先(NFS)
LOG_FILE="/var/log/backup_job.log" # 実行ログ
ADMIN_MAIL="admin@example.com" # 通知先メールアドレス
# ■処理開始
echo "------------------------------------------------" >> $LOG_FILE
echo "Backup Start: $(date '+%Y-%m-%d %H:%M:%S')" >> $LOG_FILE
# ■rsync実行
# -a : アーカイブモード (権限、タイムスタンプを維持)
# -v : 詳細出力
# -z : 転送時にデータを圧縮する (帯域節約)
# --delete : 元データで消えたファイルは、先でも消す (完全同期)
# --bwlimit=10000 : 帯域制限 (10MB/s)。業務ネットワークへの影響防止。
# --exclude : バックアップしたくないファイルがあれば指定
rsync -avz --delete --bwlimit=10000 $SRC_DIR $DEST_DIR >> $LOG_FILE 2>&1
# ■結果判定と通知
if [ $? -eq 0 ]; then
echo "Backup Success: $(date '+%Y-%m-%d %H:%M:%S')" >> $LOG_FILE
else
echo "[ERROR] Backup FAILED: $(date '+%Y-%m-%d %H:%M:%S')" >> $LOG_FILE
# メール通知(mailxパッケージが必要)
# echo "Rsyslog Backup Failed on $(hostname)" | mail -s "Backup Alert" $ADMIN_MAIL
exit 1
fi
作成したら実行権限を与えます。
chmod +x /usr/local/bin/backup_rsyslog.sh
4. スケジューリングのコツ
Cronに登録しますが、時間は適当ではいけません。
第4回のLogrotateが完了し、ファイルが圧縮された「後」に実行するのが効率的です。
crontab -e
▼設定例(Logrotateが4時に動く場合)
# 毎日 朝5:00に実行 0 5 * * * /usr/local/bin/backup_rsyslog.sh
5. 【最重要】リストア(復旧)訓練
バックアップは「戻せて」初めて成功です。実際にデータを取り出す手順を確認しましょう。
シナリオ:Webサーバー(192.168.1.10)の昨日分のログが消えた!
手順1:バックアップ先を確認
ls -l /mnt/log_backup/servers/192.168.1.10/
ここに secure-20260108.log.gz などがあるはずです。
手順2:ファイルを復元(コピー)
cp /mnt/log_backup/servers/192.168.1.10/secure-20260108.log.gz /tmp/
※直接 /var/log/ に戻すと、現在稼働中のログと混ざる危険があるため、一旦 /tmp などに戻すのが鉄則です。
手順3:解凍して中身を確認
gunzip /tmp/secure-20260108.log.gz less /tmp/secure-20260108.log
これで「いつでも戻せる」という自信が持てましたね。
連載まとめ:あなたは「システムの守護者」になった
全5回の連載、本当にお疲れ様でした!
これであなたの構築したシステムは、以下の機能を備えた「完全要塞」となりました。
- 設計: UDP/TCPを適切に使い分け、容量計算に基づいたサイジング。(第1回)
- 構築: 正確な時刻同期と、送信元を絞った鉄壁のファイアウォール。(第2回)
- 設定: RainerScriptを駆使し、ログの種類ごとに自動でフォルダ分け。(第3回)
- 運用: Logrotateによる自動圧縮と世代管理。(第4回)
- 保全: rsyncによるNFSへの全自動・差分バックアップ。(今回)
先生、ありがとうございました!
最初は「ログなんて見るだけ」と思ってましたけど、こんなに奥が深かったんですね。
リストア訓練もしたので、もし明日サーバーが壊れても焦らず対応できそうです!
ええ、素晴らしい成長よ。
ログ管理は地味だけど、システム全体の信頼性を担保する最も重要な仕事の一つ。
この経験を糧に、次はもっと大きなシステムの構築にも挑戦してみてね!
▼信頼性の高いインフラを作るなら
ログサーバーは一度構築すると数年は稼働し続ける重要なインフラです。ハードウェア故障のリスクが低く、バックアップ用ストレージの追加も簡単なVPSを選ぶことが、エンジニアの安眠を守る第一歩です。



コメント