「定期的にバックアップを実行したい」「深夜にログをローテーションしたい」——Linuxでタスクを自動実行する方法として、cron 、anacron 、systemd timer の3つが存在します。しかし、「どれを使えばいいのか」と迷う人は多いのではないでしょうか。

本記事では、これら3つのスケジューラの特性と適材適所を整理し、「結局どれを選ぶべきか」の判断基準を提供します。

3つのスケジューラの基本特性

まず、それぞれの基本的な特徴を整理します。

cron: 厳密な時刻指定のスケジューラ

cron は、UNIX系OSで最も古くから使われているタスクスケジューラです。

主な特徴:

• 厳密な時刻指定: 「毎日2時」「毎週月曜9時」のように、特定の時刻にジョブを実行
• 分単位の精度: 最小単位は1分
• 常時稼働前提: システムが24時間稼働していることを前提とした設計
• シンプルな設定: crontab形式で直感的に設定可能

設定例:

# 毎日2時にバックアップ
0 2 * * * /usr/local/bin/backup.sh

# 毎週月曜9時にレポート生成
0 9 * * 1 /usr/local/bin/generate-report.sh

適したユースケース:

• サーバーなど常時稼働するマシン
• 厳密な時刻指定が必要なジョブ（例: 営業時間外のメンテナンス）
• 分単位の細かいスケジュール（例: 5分ごとの監視）

制約:

• システムが停止していた時間帯のジョブは実行されない
• 前回のジョブが終了していなくても次のジョブが起動する（重複実行のリスク）
• ログの確認が煩雑（/var/log/syslog や /var/log/cron を探す必要がある）

anacron: 電源オフでも漏れない日次スケジューラ

anacron は、常時稼働しないマシン向けに設計されたスケジューラです。

主な特徴:

• 頻度ベースの実行: 「1日1回」「7日に1回」のように、頻度で指定
• 未実行ジョブの補完: システム起動時に、実行されていないジョブを自動的に実行
• 最小単位は日: 分単位の指定は不可
• デーモンではない: cron や systemd などから定期的に呼び出される形で動作することが多い

設定例（/etc/anacrontab）:

1
2
3
4

# period  delay  job-id  command
1         5      cron.daily    run-parts /etc/cron.daily
7         10     cron.weekly   run-parts /etc/cron.weekly
@monthly  15     cron.monthly  run-parts /etc/cron.monthly

動作の仕組み:

1. anacron は /var/spool/anacron/ にジョブの最終実行日時を記録
2. システム起動時（または cron から定期的に）、未実行のジョブをチェック
3. 指定された遅延時間（delay）後にジョブを実行

適したユースケース:

• ラップトップやデスクトップなど、電源オフの時間があるマシン
• 日次・週次・月次のメンテナンスタスク
• 厳密な時刻指定が不要なジョブ（例: バックアップ、パッケージ更新）

制約:

• 分単位の細かいスケジュールは不可
• 厳密な時刻指定ができない（起動後の遅延時間のみ指定可能）
• 標準設定では root 運用が多い（/etc/anacrontab を使う場合）

systemd timer: 現代的な統合スケジューラ

systemd timer は、systemd の一部として提供されるタスクスケジューラです。

主な特徴:

• 柔軟なスケジュール指定: 厳密な時刻、相対時刻、起動後の経過時間など多様な指定が可能
• 未実行ジョブの補完: Persistent=true で anacron と同様の動作が可能
• systemd との統合: サービス管理、ログ、依存関係などを統一的に扱える
• ランダム遅延: RandomizedDelaySec で実行時刻をランダム化可能

設定例:

タイマーファイル（backup.timer）:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

[Unit]
Description=Daily backup timer

[Timer]
OnCalendar=daily
Persistent=true
RandomizedDelaySec=1h

[Install]
WantedBy=timers.target

サービスファイル（backup.service）:

1
2
3
4
5
6

[Unit]
Description=Backup service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

適したユースケース:

• systemd を採用しているすべてのシステム
• 複雑なスケジュール要件（例: 前回実行から24時間後、起動後15分後など）
• サービス間の依存関係がある場合
• ログの一元管理が必要な場合

制約:

• systemd を使用していないシステムでは利用不可
• 設定ファイルが2つ必要（.timer と .service）で、cron より記述量が多い
• 学習コストがやや高い

3つのスケジューラの比較表

使い分けの判断基準

ケース1: サーバーで厳密な時刻指定が必要

結論: cron を使う

• 営業時間外のメンテナンス（例: 毎日深夜2時）
• 定時レポート生成（例: 毎週月曜9時）
• 高頻度の監視（例: 5分ごと）

理由:

• シンプルで学習コストが低い
• 厳密な時刻指定が可能
• 分単位の細かいスケジュールに対応

ケース2: ラップトップで日次バックアップ

結論: anacron または systemd timer を使う

• 電源オフの時間があるマシンでの日次タスク
• 厳密な時刻指定が不要なメンテナンス

anacron を選ぶ場合:

• シンプルな設定で済ませたい
• 既存の /etc/cron.daily などを活用したい

systemd timer を選ぶ場合:

• ログを journalctl で一元管理したい
• サービス間の依存関係がある
• ランダム遅延で負荷分散したい

ケース3: 複雑なスケジュール要件

結論: systemd timer を使う

• 前回実行から24時間後に実行
• システム起動後15分後に実行
• 特定のサービスが起動した後に実行

理由:

• OnBootSec, OnUnitActiveSec など多様なトリガーに対応
• サービス間の依存関係を After=, Requires= で管理可能

OnCalendar の書式やタイマーの精度（AccuracySec）については、systemd.time(7) と systemd.timer(5) も参考になります。

ケース4: 既存の cron ジョブを改善したい

結論: systemd timer に移行する

移行するメリット:

• ログが journalctl で簡単に確認できる
• 前回のジョブが終了していない場合の重複実行を防げる
• ランダム遅延で負荷分散できる
• 手動実行が簡単（systemctl start service.service）

移行手順の例:

1. crontab のエントリを確認

1
2

crontab -l
# 0 2 * * * /usr/local/bin/backup.sh

2. systemd timer と service を作成

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# ~/.config/systemd/user/backup.timer
[Unit]
Description=Daily backup timer

[Timer]
OnCalendar=02:00
Persistent=true

[Install]
WantedBy=timers.target

1
2
3
4
5
6
7

# ~/.config/systemd/user/backup.service
[Unit]
Description=Backup service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

3. タイマーを有効化

1
2

systemctl --user daemon-reload
systemctl --user enable --now backup.timer

4. 動作確認

1
2
3
4
5

# タイマー一覧を確認
systemctl --user list-timers

# ログを確認
journalctl --user -u backup.service

実践例: ラップトップでのバックアップ自動化

ここでは、電源オフの時間があるラップトップで、毎日バックアップを実行する実例を紹介します。

anacron を使う場合

1. バックアップスクリプトを作成

1
2
3
4
5
6
7

#!/bin/bash
# /usr/local/bin/backup.sh

BACKUP_DIR="/mnt/backup"
DATE=$(date +%Y%m%d)

rsync -av --delete /home/user/Documents/ "$BACKUP_DIR/$DATE/"

2. /etc/cron.daily/ に配置

1
2

sudo cp /usr/local/bin/backup.sh /etc/cron.daily/backup
sudo chmod +x /etc/cron.daily/backup

3. anacron が自動的に実行

Ubuntu/Debian では、デフォルトで anacron が /etc/cron.daily/ を毎日実行します。電源オフの時間があっても、次回起動時に未実行のジョブが補完されます。

systemd timer を使う場合

1. バックアップスクリプトを作成（同上）

2. サービスファイルを作成

1
2
3
4
5
6
7

# ~/.config/systemd/user/backup.service
[Unit]
Description=Daily backup

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

3. タイマーファイルを作成

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# ~/.config/systemd/user/backup.timer
[Unit]
Description=Daily backup timer

[Timer]
OnCalendar=daily
Persistent=true
RandomizedDelaySec=30min

[Install]
WantedBy=timers.target

4. タイマーを有効化

1
2

systemctl --user daemon-reload
systemctl --user enable --now backup.timer

5. 動作確認

1
2
3
4
5
6
7
8

# 次回実行時刻を確認
systemctl --user list-timers backup.timer

# 手動実行してテスト
systemctl --user start backup.service

# ログを確認
journalctl --user -u backup.service

systemd timer の利点:

• journalctl でログが簡単に確認できる
• RandomizedDelaySec で実行時刻をランダム化し、負荷分散できる
• Persistent=true で未実行ジョブを補完
• 手動実行が簡単（systemctl start）

よくある質問

Q1: anacron は今でも使われているのか？

A: はい、Ubuntu/Debian のデスクトップ環境ではデフォルトでインストールされ、/etc/cron.daily などの実行に使用されています。ただし、systemd timer への移行が進んでおり、新規プロジェクトでは systemd timer を選択するケースが増えています。

Q2: cron から systemd timer に移行すべきか？

A: 以下の場合は移行を検討する価値があります:

• ログの確認が煩雑で困っている
• 前回のジョブが終了していないのに次のジョブが起動してしまう
• サービス間の依存関係を管理したい
• 手動実行を頻繁に行う

一方、シンプルなジョブで cron で十分な場合は、無理に移行する必要はありません。

Q3: systemd timer の学習コストは高いか？

A: cron に比べると設定ファイルが2つ必要で、記述量は多くなります。しかし、systemctl コマンドでタイマー一覧やログを簡単に確認できるため、運用面では cron より楽になるケースが多いです。

Q4: 一般ユーザーで systemd timer を使えるか？

A: はい、~/.config/systemd/user/ にファイルを配置し、systemctl --user コマンドで管理できます。ただし、ログアウト後もタイマーが動作するようにするには loginctl enable-linger username を実行します（loginctl(1) ）。

まとめ

Linuxのタスクスケジューラは、用途に応じて使い分けることが重要です。

選択の指針:

• サーバーで厳密な時刻指定: cron
• ラップトップで日次タスク: anacron または systemd timer
• 複雑なスケジュール: systemd timer
• 既存の cron を改善: systemd timer に移行

個人的には、systemd を採用しているシステムでは、新規ジョブは systemd timer で作成し、既存の cron ジョブも徐々に移行していくのが良いと思います。ログの一元管理と重複実行防止だけでも、運用の手間が大幅に削減されます。

興味のある方は、まず簡単なジョブで systemd timer を試してみてください。

参考リンク

• cron(8) - Linux manual page
• anacron(8) - Linux manual page
• systemd.timer(5) - systemd manual
• systemd.timer(5) - Linux manual page
• systemd.time(7) - Linux manual page
• loginctl(1) - Linux manual page
• Replacing cron with systemd-timers - Anteru’s Blog
• Cron Vs Anacron: How to Schedule Jobs Using Anacron on Linux - TecMint