4
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

cronで毎日ファイルのバックアップを取る/ミラーリングファイルを用意する

Last updated at Posted at 2021-02-07

数値計算の結果をためる場合は、環境はそれほど重要ではなくて、計算結果のファイルが大事で単一のHDDにそれがあるだけでは心もとないということがよくある。できれば、異なる筐体(というか物理的に異なるディスク)にバックアップを用意したり、ミラーリングしたファイルを用意できると、安心感が増す。
Linuxで定期的な処理は、cronで実現できる。cronでは、その実行頻度を分刻みから、月刻みまで指定することができる。
ここで、日単位でバックアップ/ミラーリングを取ると結構都合がよい。ファイルの冗長性というか、オリジナルディスクが物理的に壊れたときのファイルの救出可能性を考慮すると、バックアップ/ミラーリングの頻度は高いほど良い。一方で、計算機上で手動で作業をしていると、度々ファイルを誤って消してしまうミスが起きる。この時、頻度が高いバックアップ/ミラーリングを取っていると、そのバックアップ/ミラーリング先も瞬時に同期してしまって、そのミスに気付いたときには手遅れになってしまう。もし、日単位のバックアップ/ミラーリングをしていれば、ファイルの消去に気づいたときにそうしたファイルはバックアップ/ミラーリング先に残っている可能性が極めて高い。逆に週単位で、バックアップ/ミラーリングを取っていると、元のディスクが物理的に壊れたとき、進捗が一週間前に戻ってしまうことになり、これは結構痛い。一方で、日単位でバックアップ/ミラーリングを取っている場合は、失う進捗は一日分で済む。
このようなわけで、バックアップ/ミラーリングは短すぎても長すぎても短所が顕在化する。この辺の定量的な感覚は人に依るとは思うけれども、私の感覚では日単位でとるのがベストバランスのように思える。
と言うわけで毎日バックアップ/ミラーリングをするという処理をcronでどう実装するかをまとめる。頻度を低くしたり、高くしたりしたければcronの設定を適宜変えればよい。

cronの設定

基本となるコマンドはcrontab。例えばcrontab -lで、今現在登録されている定期実行処理が表示される。事前に設定していなければno crontab for hogehogeと標準出力が返ってくるはず。
crontabへの定期実行処理の追加はcrontab -eでも出来るらしい。他のオプションとしてはcron.confという登録用ファイルを用意して、そこに追加する方法もある。好みの都合で、私は後者を採用した。
毎日4:00AMにbackup.shを実行する設定は以下の設定ファイルで実現できる:

cron.conf
0 4 * * * /root/cronfiles/backup.sh

この/root/cronfiles/backup.shの前のスペースで分かれた五つの欄はそれぞれ、分、時、日、月、曜日になっていて、*が挿入されている箇所は任意の整数値に実行される。例えばこの個所を* 4 * * *だと毎日午前4時台に毎分処理が実行されることになるので、注意。
このファイルを準備してcrontab cron.confで登録される。crontab -lで登録されていることが確認できる。

参考にしたページ
cronを用いたコマンドの定期実行 - アメリエフのブログ
定期実行の手法3パターンとその活用例 - Qiita

トラブルシューティング

スクリプト内のいくつかのコマンドが使えない

cronの環境変数について - Qiitにもあるとおり、かなり限定的なところにしかpathが通っていないよう。全体の設定をいじっても良いが、私のケースでは該当のスクリプト内でexport PATH=/path/to/be/reffered:$PATHとして、明示的に必要なpathを追記した。

backup.shの中身

バックアップを取りたい計算機のホスト名をここではhoge001とする。バックアップを取る際には、もちろんhoge001の中で異なるディスクにrsyncをしても良い。ここでは、hoge001でnfsサーバーが動いていることを使って、nfsクライアント側の筐体でこれを/hoge001_homeにread-onlyでマウントした状況を考える。
こうするメリットとして、read-onlyオプションによって、同期元のファイルを原理的に編集できなくする点が挙げられる。同じ筐体の中でrootアカウントでファイル操作をする場合は、こうした形で制限をかけるのは難しい。nfsでのマウントを介することで、サーバー側ではreadとwriteを許可しても、クライアント側でread-onlyを選ぶ(/etc/fstabに適宜記載)ことで安全性を高めることができる。
サンプルのスクリプトファイルは以下の通り:

backup.sh
# !/bin/bash
DATE=`date +'%Y_%m_%d'`
# rsync -avn --delete /hoge001_home /backup/ #For dry run
rsync -av --delete /hoge001_home /backup/ > /root/cronfiles/backup_log_files/"backup_log_$DATE.log"

このスクリプトを実行すると、rsyncをアーカイブモード(-aオプション)で処理の情報を書き出す(-vオプション)で同期をする。--deleteがついているので、同期元で消えたファイルは同期先でも消去され、ミラーリングになっている。
三行目の#でコメントアウトされたものは追加で-nオプションがついている。これはdry-run用のオプションで、このコマンドを実行した際に、実際にはファイルへの操作は行わずに、具体的にどのファイルが同期されるのか、どのファイルが消去されるのかを標準出力で教えてくれる。例えば標準出力をテキストに書き出しておいてdeletingなどのキーワードで検索を書ければ、消してしまっては困るファイルが表示されて、事前にそれに気付けるかもしれない。
二行目の変数DATEに日付を代入してあり、標準出力に同期をとった日付の情報を付け加えている。
このスクリプトはcronから実行するには多分実行権限が継いでいる必要があるので、chmod 755 backup.shで実行権限を付与する。

4
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?