【logrotate講座 最終回】最強のバックアップ構築。S3への自動転送とログ一元管理への応用

サーバーが燃えても、ログだけは守り抜け。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
ついに、全8回にわたるlogrotate講座も最終回を迎えました。

これまでの講座で、あなたはログを適切に回し、圧縮し、権限を管理するスキルを身につけました。
しかし、それらはすべて「サーバーが無事であること」が大前提の話です。
もし明日、サーバーのディスクが物理的に破損したら？
もし、悪意あるハッカーに侵入され、rm -rf /var/log/* されたら？
あなたの手元には、何も残りません。

本記事では、AlmaLinux 9 をベースに、AWS CLIの導入から、S3への転送スクリプトの作成、そしてログ一元管理の設計思想まで、プロの運用ノウハウを余すところなく解説します。

---

第1章：なぜ「S3」への転送なのか？

バックアップ先として、AWS S3（Amazon Simple Storage Service）などのオブジェクトストレージが選ばれるには明確な理由があります。

1. 圧倒的な耐久性（イレブン・ナイン）

S3のデータ耐久性は「99.999999999%」です。
自前でバックアップサーバーを立てるよりも遥かに安全にデータを守ってくれます。

2. 容量無制限

ディスク容量を気にする必要がありません。
数年分のログを溜め込んでも、S3が溢れることはありません。

3. ライフサイクルによるコスト削減

「30日経過したログは、さらに安いアーカイブクラス（Glacier）へ移動する」「1年経過したら削除する」といったルールを自動化できます。
これにより、保管コストを極限まで下げることができます。

---

第2章：AWS CLI の導入と準備

logrotateからS3へファイルを送るために、AWS公式のコマンドラインツール AWS CLI をインストールします。
※AWSアカウントとS3バケット（例: my-server-logs-bucket）は作成済みとします。

1. AWS CLIのインストール

AlmaLinux 9 では、zipファイルをダウンロードしてインストールするのが確実です。

sudo dnf install unzip -y
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

# 確認
aws --version

2. IAMユーザーの作成と権限設定（重要）

サーバーに強い権限（AdministratorAccessなど）を持たせるのは危険です。
「指定したS3バケットへの書き込み（PutObject）だけができる」専用のIAMユーザーを作成し、そのアクセスキーを使います。

ポリシー例：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::my-server-logs-bucket/*"
        }
    ]
}

3. サーバーでの認証設定

logrotateはroot権限で動くため、rootユーザーに対して設定を行います。

sudo su -
aws configure
# Access Key ID, Secret Access Key, Region (ap-northeast-1など) を入力

---

第3章：lastaction ディレクティブの活用

いよいよ logrotate と S3 を連携させます。
ここで使うのが lastaction ディレクティブです。

postrotate との違い

• postrotate: ログのリネーム後、圧縮される前に実行されることが多い（delaycompress の有無による）。また、sharedscripts がないとファイルごとに実行される。
• lastaction: 全てのローテーション処理（圧縮含む）が完全に終わった最後に、1回だけ実行される。

バックアップ転送は「圧縮された後のファイル」を送りたいので、lastaction が最適です。

設定ファイル例

/etc/logrotate.d/httpd を編集します。

/var/log/httpd/*log {
    daily
    rotate 30
    missingok
    notifempty
    compress
    delaycompress
    dateext
    sharedscripts
    
    # サービスの再起動
    postrotate
        /bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true
    endscript
    
    # S3への転送（ここを追加）
    lastaction
        # ホスト名を取得（識別用）
        HOSTNAME=$(hostname)
        # 今日の日付（圧縮されたファイルに付く日付）
        DATE=$(date +%Y%m%d)
        
        # S3へ同期（コピー）
        # excludeで現在書き込み中の生ログ(*.log)を除外するのがコツ
        /usr/local/bin/aws s3 sync /var/log/httpd/ s3://my-server-logs-bucket/$HOSTNAME/ \
          --exclude "*" --include "*.gz" --quiet
    endscript
}

解説：aws s3 sync の威力

aws s3 cp で1つずつ送るのも良いですが、sync コマンドを使うと、「まだS3にないファイルだけ」を賢く転送してくれます。
--exclude "*" --include "*.gz" とすることで、圧縮された過去ログだけを対象にし、現在書き込み中の access.log を送らないようにしています。

---

第4章：転送スクリプトの強化（エラーハンドリング）

設定ファイルに直接コマンドを書くと長くなる場合、別のシェルスクリプトファイルに切り出して、それを呼び出すのがスマートです。

転送スクリプト (backup_logs.sh)

#!/bin/bash

LOG_DIR="/var/log/httpd/"
BUCKET="s3://my-server-logs-bucket/$(hostname)/"

# S3へ転送
/usr/local/bin/aws s3 sync $LOG_DIR $BUCKET --exclude "*" --include "*.gz" --quiet

# 終了コードのチェック
if [ $? -eq 0 ]; then
    logger -t logrotate_s3 "S3 backup success"
else
    logger -t logrotate_s3 "S3 backup FAILED"
    # ここでSlack通知などを送るとさらに良い
fi

logrotateからの呼び出し

    lastaction
        /usr/local/bin/backup_logs.sh
    endscript

これで、ログ（/var/log/messages）に成功・失敗が記録されるようになり、トラブルシューティングが容易になります。

---

第5章：ログ一元管理（集約）の設計思想

サーバーが1台なら上記の方法で十分ですが、サーバーが10台、100台と増えたらどうでしょうか？
各サーバーからバラバラにS3へ送るのではなく、「ログ集約サーバー」を作るアプローチもあります。

rsyslog による転送

Linux標準の rsyslog を使えば、リアルタイムでログを別のサーバーへ転送できます。

1. Webサーバー群: ログをローカルに書かず、集約サーバーへ送信する。
2. 集約サーバー: 全台分のログを受け取り、/var/log/hosts/web01/access.log のように保存する。
3. 集約サーバーのlogrotate: まとめてローテーションし、S3へバックアップする。

この構成のメリットは、Webサーバー側にAWSの認証情報（アクセスキー）を持たせなくて済むため、セキュリティが高まることです。

Fluentd / CloudWatch Logs との比較

最近は Fluentd や CloudWatch Logs エージェント を使って、リアルタイムにログをクラウドへ送るのが主流になりつつあります。

ツール	特徴	logrotateの役割
logrotate + S3	シンプル、安価、設定だけで完結。1日1回のバッチ転送。	主役。ログ管理の全てを担う。
Fluentd (TD Agent)	高機能、リアルタイム、複雑なフィルタリングが可能。	脇役。Fluentdが読み終わったローカルログを消すために必要。
CloudWatch Logs	AWS完全マネージド。検索機能が強力だが、量が多いと高い。	脇役。エージェントが転送済みのログを消すために必要。

どのツールを使うにせよ、サーバー内にテキストファイルとしてログが出力される限り、「ディスクを溢れさせないための掃除役」としての logrotate は不要になりません。

---

第6章：S3ライフサイクルによるコスト削減

S3に転送した後も、「ゴミ」を溜め込まない工夫が必要です。
AWSコンソールから、S3バケットの「ライフサイクルルール」を設定しましょう。

おすすめの設定例

• 移行アクション: 作成から30日後に「Glacier Instant Retrieval」へ移行。
  （保管料が標準の約40%安くなる）
• 有効期限アクション: 作成から365日（1年）後にオブジェクトを削除。
  （監査要件に合わせて調整）

これを設定しておけば、一度logrotateの設定をするだけで、あとは全自動で「生成→転送→アーカイブ→廃棄」のサイクルが回り続けます。
これぞ、インフラエンジニアが目指すべき「完全自動化」の世界です。

---

全8回まとめ：あなたは「ログマスター」になった

お疲れ様でした！
これにて「logrotate完全攻略講座」は完結です。

全8回で習得したスキル：

1. 仕組みの理解: logrotateがcronで動く仕組みと、設定ファイルの構造。
2. 設定の自在な制御: 期間、サイズ、圧縮、日付付与の使いこなし。
3. ファイルシステムの理解: iノードと create / copytruncate の正しい使い分け。
4. スクリプト連携: postrotate によるサービス制御と自動化。
5. セキュリティと権限: su ディレクティブとACL、SELinux対策。
6. トラブルシューティング: デバッグモードとステータスファイルの解析。
7. バックアップ戦略: クラウドストレージへの自動転送とライフサイクル管理。

ログ管理は、派手なWEBサイト制作やAI開発に比べると「地味」な仕事です。
しかし、システムが障害を起こした時、ハッキングを受けた時、最後に頼りになるのは「ログ」だけです。
そして、そのログを正常に保ち続ける logrotate は、システムの生命維持装置そのものです。

この講座で得た知識は、AlmaLinuxだけでなく、UbuntuやDebian、あるいはコンテナ環境（Docker/Kubernetes）のログ設計においても必ず役に立ちます。
自信を持って、サーバーを守り続けてください。

長い間お付き合いいただき、ありがとうございました。
あなたのエンジニアライフが、エラーログのない（あるいはすぐに解決できる）平穏なものでありますように！ Happy Logging!