UNIXやLinuxのシステム管理（システム・コマンド・設定）に関する世界観８B（cron）です。
定期的に特定の処理を実行してくれる。決まった時間にコマンドを実行することが出来る。
「サーバーマシンのバックアップやアーカイブの作成なんか、勝手にやってほしい」とか、「NFSに適当に定期的にコピーしてほしい、それもバックグラウンドで」とか、そういう、「バックグラウンドで定期的にやってほしい」というサーバー管理者の想いを叶えてくれるのがcronです。
基本的には、定期的に実行する「スケジュール」と、やってほしい「処理」を書くだけです。処理にはシェルスクリプトを書くこともできます。
特に、サーバー管理者のタスクとして、Apacheの設定やSSHでのリモートログインに匹敵する重要なタスクがcronです。ただ、書く処理を間違えると悲惨なことになるので、良く確認しましょう。
バックアップをUNIXで行う時は、rsyncを使って全ファイルをフォルダごと同期するか、tarを使ってアーカイブを日ごとに作っていくか、どちらかを選択することが多いでしょう。古いアーカイブは自動的に消すようにしても良いでしょう。簡単に一行では書けないところもあるので、詳しくはネットで検索してその情報に頼ってください。
自分でサーバーのWebアプリケーションを開発するのであれば、最初からMySQLなどで一元的にデータベースを管理することも、信頼性の確保に繋がります。ですが、レンタルサーバーのような場合、全ての顧客のデータをSQLで一元化することは難しいこともあります。cronでrsync/tarを行うのは、そういうニーズが根強いためです。SQLデータベースの使える環境では、最初からRDBMSを使いましょう。
SQLデータベースを使う場合は、「差分のバックアップ」と「全体のバックアップ」を上手く管理する必要があります。それぞれのデータベース管理システムで、こうした機能は必ずあります。UNIXのファイルシステムには、そもそも、バージョンを管理する機能もありません。バージョンを管理したい時は、gitなどのバージョン管理システムでひとつひとつコミットするか、あるいはtarで毎日バックアップするしかありません。そういうわけで、cronには限界がありますが、使えないわけではありません。
注意：UNIXでのバックアップとしてtarやrsyncが一般的であるかのようなことを書きましたが、FreeBSDハンドブックにもあるように、多くの場合UNIXで最も一般的なのはdumpとrestoreというコマンドで、/dev/sda1のようなブロック型のデバイスをいっぺんにバックアップ・復旧することができます。ですが、イメージファイルが巨大になる上に、イメージ単位でのバックアップになるため、ファイルシステムの一部だけをバックアップしたり、複数のファイルシステムにまたがるディレクトリツリーをバックアップすることができません。dumpとrestoreは、大事なデータのバックアップというよりも、システム全体の復旧をしたい時に有効です。通常、大事なデータのバックアップには、tar, rsync, cpioなどのコマンドを使います。ですが、システム管理者になりたいのであれば、dump, restore, ddなどのコマンドも覚えておくと良いでしょう。
後日注記：そもそも、データベース管理システムを使う場面というのは、「億単位のデータから瞬時に検索する」場合のように、本当にデータの信頼性と性能が必要な場合だけです。多くの設定ファイルや個人データなどで、データベース管理システムを使うというのは考えられません。よって、そうしたデータはcronでバックアップを取りましょう。その代り、上手くやらなければ「たくさん圧縮ファイルが生まれて訳が分からない」ことになるので、古いデータは自動で削除するなどの処理をスクリプトに書いて、そのスクリプトをcronで実行するようにします。
システムのcrontab（/etc/crontab）の書式は以下のようになる。
* * * * * 実行ユーザー名 コマンド
設定項目は左から分、時、日、月、曜日となっている。*を指定すると指定しないことになる。
ユーザーのcrontabは、crontab -eコマンドで設定する。このファイルは/var/spool/cron/以下に配置される。
$ crontab -e
crontab -eコマンドを使用した場合、実行ユーザー名については記述しなくてよい。
たとえば、
00 23 * * 5 bash /home/assy/for_cron.sh
とすれば、毎週金曜日の23:00にスクリプトを実行してくれる。
/etc/crontabはこのようになっていることが多い（一部分のみ）。
17 * * * * root run-parts /etc/cron.hourly 25 6 * * * root run-parts /etc/cron.daily 47 6 * * 7 root run-parts /etc/cron.weekly 52 6 1 * * root run-parts /etc/cron.monthly
run-partsはディレクトリ以下にあるすべてのスクリプト・プログラムを実行するコマンド。
設定ファイルはこのように使い分ける。
| ファイル | ユーザ | 説明 |
|---|---|---|
| /var/spool/cron/[ユーザー名] | 全ユーザ | ユーザ別のcron設定ファイル |
| /etc/crontab | root | メインのcron設定ファイル |
| /etc/cron.hourly | root | 毎時一回実行されるディレクトリ |
| /etc/cron.daily | root | 毎日一回実行されるディレクトリ |
| /etc/cron.monthly | root | 毎月一回実行されるディレクトリ |
| /etc/cron.weekly | root | 毎週一回実行されるディレクトリ |
| /etc/cron.d | root | その他の設定を入れるディレクトリ |
（cron の設定ガイド - Linuxべんりな動作情報 ナレッジベース：環境設定 - Express5800シリーズポータル - NECを参考に執筆しました。/etc/crontabの記述についてはDebian 11の/etc/crontabを参考に編集しています。）
以下は、毎日のデータをアーカイブしてバックアップする例。
まず、以下のようなシェルスクリプトを書く。
#!/bin/bash DATA_DIR=/home/assy/data BACKUP_DIR=/home/assy/data_backup FILENAME=$(date +%Y.%m.%d).data_backup.tar.gz cd $BACKUP_DIR tar czpf $FILENAME $DATA_DIR
まず、dateは現在の年と月と日を得る。+の後に続く文字列がフォーマットを表し、%Yが年、%mが月、%dが日に自動で変換される。
次に、tarのオプションは、cがアーカイブ作成、zがgzip形式で圧縮、pが所有者やパーミッションなどのファイル属性の保持、fがファイル名の指定を意味する。
このファイルを/home/assy/assy_data_backup.shとし、実行可能のパーミッション属性を与える。
$ chmod u+x /home/assy/assy_data_backup.sh
そしてcrontab -eコマンドを実行し、
$ crontab -e
以下のように記述する。
30 23 * * * bash /home/assy/assy_data_backup.sh
/etc/crontabを編集する場合は、実行ユーザー名を指定する。
30 23 * * * assy bash /home/assy/assy_data_backup.sh
これで、毎日23時30分にバックアップファイルをアーカイブしてくれる。
一度、cronではなく直接実行してみて、きちんと動くかどうかを試してみよう。
$ bash /home/assy/assy_data_backup.sh
以下のページが参考になります。
以下が参考になる。
bcron, dcron, fcron, cronieはそれぞれ、cronデーモンを提供するパッケージ。
anacronはcronと同等の定期的実行システムだが、システムが24時間常に稼働することを前提としない。たまに起動するシステムであってもcronと同等の定期実行が行える。
cronと異なり最小でも一日単位でしか定期実行できないが、もし実行すべきタイミングでシステムが稼働していなかったら、後になってその実行をもう一度行ってくれる。
システムロガーと同様、長らくcronだった定期的な時間処理は、systemd timerを使ってやるようになった。
systemdを参照のこと。
cronは難しいと思われるかもしれないが、基本的にシェルスクリプトを作ってcron.dailyなどに放り込めばよい。
スクリプトにchmodで実行権限をつけておこう。
systemdに移行したディストリビューションであっても、引き続きcronを使い続けられることが多い。