【サーバー管理入門 第10回】管理者を「手作業」から解放する。Cronとシェルスクリプトによる全自動化
こんにちは！「リナックス先生」です。
前回は、ログ管理とjournalctlの使い方を学び、サーバーの健康状態を把握できるようになりました。
コウ君、第8回でデータベースのバックアップ方法（mysqldump）を教えたけれど、あれから毎日ちゃんとバックアップ取ってる？
えっ……あー、その……。
最初の3日間くらいは手動でコマンドを打ってたんですけど、最近は忙しくて……。
「今日はまあいいか」ってサボっちゃってます。
正直でよろしい（笑）。でも、障害はそういう「油断した日」に限って起きるものよ。
人間は忘れるし、ミスをする生き物。
だからプロの管理者は、決まりきった作業を絶対に人間にはやらせないの。
今回は、サーバーの中の執事「Cron（クーロン）」を使って、全てのルーチンワークを全自動化するわよ！
第10回となる今回は、サーバー管理の効率を劇的に向上させる「自動化技術」について解説します。
指定した日時にコマンドを実行する Cron の設定方法から、バックアップを自動化する 「実用的なシェルスクリプト」 の作成まで、現場で即戦力となるスキルを習得しましょう。
本講座のカリキュラム
- サーバー管理入門：RHEL系OSの選定理由とローカル仮想環境の構築
- 初期設定とセキュリティの要：SSH鍵認証、禁止設定、ユーザー管理の鉄則
- パッケージ管理の裏側：dnf/rpmの仕組みとリポジトリの依存関係解決
- ネットワーク設定の極意：nmcli、IPアドレス設計、DNSリゾルバの設定
- ストレージ管理とファイルシステム：LVMの概念、ディスク拡張、fstabの罠
- プロセスとサービス管理：systemd (systemctl) の仕組みとUnit定義ファイルの作成
- Webサーバー構築(Nginx)：ハイパフォーマンスWebサーバーの導入と設定最適化
- データベース構築(MariaDB)：インストール、初期セキュリティ、バックアップの基礎
- ログ管理とトラブルシュート：rsyslog、journalctl、ログローテートの設計
- 【今回】自動化の第一歩：Cronによる定期実行と管理用シェルスクリプトの作成
- バックアップと障害復旧：tar/rsyncによるデータ保全とリカバリ手順
- 監視と運用設計：サーバーのリソース監視、死活監視、そしてプロの運用論
1. 定期実行の守護神「Cron」とは
Cron（crond）は、あらかじめ指定したスケジュールに従って、コマンドやスクリプトを自動実行してくれる常駐デーモンです。
「毎朝4時にバックアップ」「5分おきに監視」「月曜日の朝だけメール送信」といったことが可能です。
設定ファイルの種類
Cronの設定場所は大きく分けて2つあります。
- システム設定 (
/etc/crontabなど)： root権限でシステム全体のタスクを管理する場合に使います。ユーザー名の指定が必要です。 - ユーザー設定 (
crontab -e)： 各ユーザーが個別に設定する場合に使います。基本的にはこちらを使います。
2. Cronの書き方（呪文の解読）
Cronの設定は、スペース区切りの5つの数字（または記号）と、実行するコマンドで構成されます。
この並び順を暗記するのが最初のステップです。
# 書式 分 時 日 月 曜日 実行したいコマンド
| フィールド | 入力可能な値 | 例 |
|---|---|---|
| 分 | 0〜59 | 0 (毎時0分) |
| 時 | 0〜23 | 4 (朝4時) |
| 日 | 1〜31 | 1 (毎月1日) |
| 月 | 1〜12 | * (毎月) |
| 曜日 | 0〜7 (0,7は日曜) | 1 (月曜) |
便利な記号（ワイルドカード）
*：すべて（毎回）,：リスト指定（例：0,30→ 0分と30分に）-：範囲指定（例：9-17→ 9時から17時の間）/：間隔指定（例：*/5→ 5分ごとに）
設定例クイズ
Q1. 30 8 * * *
A. 毎日 朝8時30分 に実行
Q2. 0 */3 * * *
A. 3時間おき（0時, 3時, 6時…）の0分 に実行
Q3. 0 9 * * 1-5
A. 平日（月〜金）の朝9時00分 に実行
3. 実践：バックアップ用シェルスクリプトの作成
Cronには直接長いコマンドを書くこともできますが、プロは「処理をまとめたシェルスクリプト」を作成し、Cronからはそのスクリプトを呼び出すように設定します。
こうすることで、複雑な処理（エラー処理、古いファイルの削除など）が可能になるからです。
今回は、第8回で作成したデータベース webapp_db をバックアップし、さらに「過去7日分より古いファイルは自動削除する」スクリプトを作りましょう。
スクリプト作成
管理者用のスクリプト置き場として /root/bin を作成し、そこに配置します。
[root@server01 ~]# mkdir -p /root/bin [root@server01 ~]# vi /root/bin/backup_db.sh
backup_db.sh の内容：
#!/bin/bash
# --- 設定変数 ---
BACKUP_DIR="/backup/db"
DB_NAME="webapp_db"
DB_USER="root"
DB_PASS="ここにrootパスワード"
DATE=$(date +%Y%m%d_%H%M)
FILE_NAME="${DB_NAME}_${DATE}.sql.gz"
# --- 準備 ---
# バックアップ保存先がなければ作る
mkdir -p $BACKUP_DIR
# --- バックアップ実行 ---
# mysqldumpの結果をgzipで圧縮して保存
mysqldump -u $DB_USER -p$DB_PASS $DB_NAME | gzip > $BACKUP_DIR/$FILE_NAME
# 実行結果の判定 ($? は直前のコマンドの成功/失敗が入る変数)
if [ $? -eq 0 ]; then
echo "SUCCESS: Database backup created at $BACKUP_DIR/$FILE_NAME"
# --- 古いファイルの削除 (7日以上前) ---
# findコマンドで古いファイルを探して削除する
find $BACKUP_DIR -name "${DB_NAME}_*.sql.gz" -mtime +7 -delete
echo "CLEANUP: Old backups deleted."
else
echo "ERROR: Database backup failed!" >&2
exit 1
fi
💡 ポイント：セキュリティ
このスクリプトにはDBのパスワードが平文で書かれています。
必ず「rootユーザー以外は見られない」ように権限を設定してください。
[root@server01 ~]# chmod 700 /root/bin/backup_db.sh
動作テスト
まずは手動で実行して、エラーが出ないか確認します。
[root@server01 ~]# /root/bin/backup_db.sh SUCCESS: Database backup created at /backup/db/webapp_db_20240125_1000.sql.gz CLEANUP: Old backups deleted.
/backup/db/ ディレクトリにファイルが生成されていれば成功です。
4. Cronへの登録と「環境変数の罠」
スクリプトが完成したので、これを毎日深夜3時に実行するようCronに登録します。
crontabの編集
[root@server01 ~]# crontab -e
viエディタが開くので、以下の行を追記します。
0 3 * * * /root/bin/backup_db.sh >> /var/log/db_backup.log 2>&1
⚠️ プロの極意：ログ出力とフルパス
1. 出力の保存：
Cronで実行されたコマンドの出力結果は、通常捨てられるか、root宛てにメールで飛びます。>> /var/log/db_backup.log 2>&1 と書くことで、実行結果（エラー含む）をログファイルに追記保存できます。「動かない！」という時の調査に必須です。
2. フルパス記述：
Cron実行時は、通常のログイン時と違って PATH （コマンドの検索場所）が通っていないことが多いです。
スクリプト内では mysqldump ではなく /usr/bin/mysqldump と書くか、スクリプトの先頭でPATHを定義するのが安全です。
登録の確認
[root@server01 ~]# crontab -l 0 3 * * * /root/bin/backup_db.sh >> /var/log/db_backup.log 2>&1
5. トラブルシューティング：Cronが動かない時
「設定したはずなのに動いていない」
そんな時は以下の3点を確認してください。
1. Cronのログを確認
Cron自体がコマンドを実行しようとしたかは、/var/log/cron に記録されます。
[root@server01 ~]# grep "backup_db" /var/log/cron Jan 25 03:00:01 server01 CROND[1234]: (root) CMD (/root/bin/backup_db.sh ...)
これが出ていれば、「Cronは仕事をしたが、スクリプト側でエラーが出ている」可能性が高いです。
2. スクリプトの実行権限
スクリプトに chmod +x (実行権限) がついているか再確認しましょう。
3. %記号のエスケープ
Cronの設定行に直接 date +%Y%m%d などを書く場合、% は「改行」として扱われる特殊記号です。
Cron定義ファイル内で使う場合は \% とエスケープする必要があります。
※ 今回のようにスクリプトファイルの中に書く場合はエスケープ不要です。だからこそスクリプト化が推奨されるのです。
次回予告：壊れたサーバーを蘇らせる
今回は、サーバー管理者の心強い味方、Cronによる自動化を学びました。
これで毎晩自動的にデータベースのバックアップが取られ、古いものは削除されるサイクルが完成しました。枕を高くして眠れますね。
しかし、「バックアップがある」だけで安心していませんか？
「バックアップから正しく戻せるか」を試したことはありますか？
次回は、実際にサーバーのデータを削除して障害を発生させ、そこからバックアップデータを使ってシステムを復旧させる「リストア訓練」を行います。
インフラエンジニアとしての真価が問われる回です。お楽しみに！
自動化は便利だけど、間違ったスクリプトを登録すると「毎朝3時にシステムを破壊する」時限爆弾にもなり得るわ。
必ず手動でテストをして、想定通りに動くことを確認してからCronに登録する癖をつけてね。
VPSなら、もし失敗しても「スナップショット」機能で時間を巻き戻せるから、検証には最適よ。
Cronの動作検証や、自作スクリプトのテスト環境として、自由に壊してやり直せるVPS（仮想専用サーバー）を持っておくことを強くお勧めします。
私も開発環境として愛用している、初心者にも使いやすくコスパ最強のVPSを以下に紹介しておきます。
▼スクリプトの実験場に最適！推奨VPS
コメント