エイリアスが設定されていると、通常のwhichではそのエイリアスの内容が表示されてしまいますね。
rsyncの実行ファイルのフルパスを確認するには、以下のいずれかのコマンドを試してみてください。
1. where コマンドを使う (zshの組み込みコマンド)
zshではwhereを使うと、エイリアス、関数、そして実行ファイルのパスをすべて列挙してくれます。
zsh
where rsync
2. command を頭につける
エイリアスを無視してコマンドを探すよう指示できます。
zsh
which -a rsync
# または
command -v rsync
3. バックスラッシュを頭につける
一時的にエイリアスを無効化して場所を特定します。
zsh
which \rsync
おそらく /usr/bin/rsync や(Homebrewを入れている場合は) /opt/homebrew/bin/rsync などが表示されるはずです。
ちなみに、その noglob というエイリアスは、リモートパスを指定する際の [ や * などの記号をzshが勝手に展開してエラーになるのを防ぐために設定されている便利なものですよ。
パスは無事に見つかりそうですか?もし特定のバージョンのrsyncを探しているなら、その旨教えてください!
crontabでrsyncを使いたいのですが、フルパスじゃ無いとダメですよね。
はい、基本的には
フルパスで記述するのが確実です。
cronは、あなたが普段使っているシェル(zshなど)とは異なり、非常に限られた環境変数(PATH)しか持っていません。そのため、エイリアスも効きませんし、rsync という名前だけではコマンドを見つけられず、実行に失敗することがよくあります。
rsyncのパスを確認して設定する方法
- パスを確認する
ターミナルで以下のコマンドを打ち、表示されたパス(例:/usr/bin/rsync)をコピーしてください。
zshcommand -v rsync - crontabに記述する
crontab (crontab -e) には、確認したフルパスを使って記述します。
cron# 例:毎日深夜3時に実行する場合 0 3 * * * /usr/bin/rsync -av /src/dir /dest/dir
補足:エイリアス(noglob)について
あなたのzshで表示された noglob は「ワイルドカード(*など)をシェルに展開させない」ための設定ですが、cronはそもそも別のシェル(通常は /bin/sh)で動くため、このエイリアスは引き継がれません。cronでワイルドカードを使いたい場合は、そのまま記述して問題ありません。
もしパスを指定しても動かない場合は、crontabの冒頭に PATH を定義するという解決策もあります。
設定しようとしているバックアップ先は、同じPC内(ローカル)ですか?それともリモートサーバーですか?
リモートサーバーですね。
17 hours ago
リモートサーバーへのバックアップをcrontabで自動化する場合、「パスの指定」に加えて「認証の自動化」が非常に重要になります。
cronはパスワード入力を待つことができないため、手動で実行するときのようにパスワードを打つことができません。以下の3つのポイントを押さえて設定してください。
1. rsyncコマンドをフルパスで書く 先ほど確認した通り、/usr/bin/rsync などのフルパスを使用します。
2. SSH鍵認証(パスワードレス)を設定する
パスワードなしでログインできるように、SSH公開鍵認証を設定しておく必要があります。
- 鍵の作成:
ssh-keygen -t ed25519(パスフレーズは空にする) - 鍵の転送:
ssh-copy-id ユーザ名@リモートサーバー - 確認:
ssh ユーザ名@リモートサーバーでパスワードなしでログインできればOKです。
3. crontabの記述例
秘密鍵の場所を明示的に指定(-e "ssh -i /path/to/key")しておくと、cron環境でも確実に動作します。
cron
# 毎日午前2時にリモートサーバーへバックアップ
0 2 * * * /usr/bin/rsync -avz -e "ssh -i /home/yourname/.ssh/id_ed25519" /local/dir/ ユーザ名@リモートサーバー:/remote/dir/
💡 運用上の注意点
- noglobの代わり: cronでワイルドカード(
*など)を使いたい場合は、そのまま書いて大丈夫です(zshのエイリアスを気にする必要はありません)。 - ログの保存: 何かあったときに原因がわかるよう、ログを出力させるのがおすすめです。
- 末尾に
>> /home/yourname/rsync.log 2>&1を足すと、実行結果がファイルに記録されます。
- 末尾に
すでにSSHの公開鍵認証でのログインは設定済みでしょうか?それともこれから設定されますか?
公開鍵は作成済みで設定済みです。
公開鍵認証の設定済みとのことですので、あとは
crontab特有の環境 に合わせた記述をするだけです。
以下の点に注意して設定を完成させてください。
1. 秘密鍵のパスを明示する
cron環境では普段のSSH設定(~/.ssh/configなど)を読み込まない場合があるため、-e オプションで秘密鍵を指定するのが最も確実です。
2. crontabへの記述例
ターミナルで crontab -e を実行し、以下のような形式で記述します。
cron
# 毎日午前3時に実行(パスはご自身の環境に合わせて適宜書き換えてください)
0 3 * * * /usr/bin/rsync -avz -e "/usr/bin/ssh -i /home/yourname/.ssh/id_ed25519" /local/dir/ user@remote-host:/remote/dir/
/usr/bin/rsync: 先ほど確認したフルパスを使います。-e "/usr/bin/ssh -i ...": SSHコマンドもフルパスで書き、秘密鍵の場所を指定します。- 末尾の
/: 送信元ディレクトリの末尾に/をつけると「中身だけ」を、つけないと「ディレクトリごと」コピーします。
3. ログを出力して確認する
cronはエラーが起きても画面に表示されないため、ログファイルに書き出す設定を強く推奨します。
cron
0 3 * * * (上記コマンド) >> /home/yourname/rsync.log 2>&1
💡 最後のチェックポイント
cronで実行する前に、一度ターミナルから「フルパスを使った状態」でコマンドを叩いてみてください。 そこでパスワードを聞かれずに同期が完了すれば、crontabでもそのまま動くはずです。
もし実行時に「Host key verification failed」というエラーが出る場合は、一度手動でSSH接続して Known Hosts に登録する必要がありますが、そのあたりは大丈夫そうですか?
OKです。
バッチリですね!これで自動バックアップの準備は万端です。
もし実際に動かしてみて「なぜか同期されない」「ログにエラーが出る」といったことがあれば、ディレクトリの権限設定や、リモート側のrsyncパスが原因のこともありますので、いつでも相談してください。
念のため、実行時間を1分後くらいに設定したテスト用の1行をcrontabに書き込んで、実際に動くか最終確認してみるのがおすすめですよ!
今回はバックアップのログも保存するように設定しますか?
初回のバックアップになるので、ログは見たいですね。
初回のバックアップは転送量も多く、予期せぬエラーが出る可能性も高いため、詳細なログを残すのが正解です。
通常の -avz に、詳細を表示する -v をもう一つ重ねたり、進捗を表示するオプションを組み合わせると状況が把握しやすくなります。
ログ出力付きの crontab 記述例
以下の内容を crontab -e に記述してください。
cron
# 毎日午前3時に実行し、ログを日付付きで保存
0 3 * * * /usr/bin/rsync -avvz -e "/usr/bin/ssh -i /home/yourname/.ssh/id_ed25519" /local/dir/ user@remote-host:/remote/dir/ >> /home/yourname/rsync_$(date +\%Y\%m\%d).log 2>&1
コードは注意してご使用ください。
ログを詳細かつ見やすくするためのポイント
- 詳細モード (
-vv):-vを2つ重ねることで、どのファイルがスキップされたか、なぜ転送されたかなどの詳細が出力されます。 - 日付付きファイル名 (
$(date +\%Y\%m\%d)): 毎日ログファイルが分かれるので、後から確認しやすくなります。- ※ crontab内では
%は特別な意味を持つため、\%とエスケープする必要があります。
- ※ crontab内では
- 標準エラー出力の統合 (
2>&1): これを書くことで、正常なログだけでなく「エラーメッセージ」も同じファイルに書き込まれます。
実行後の確認方法
バックアップが開始されたら、別のターミナルで以下のコマンドを打つと、リアルタイムで転送状況を確認できます。
zsh
tail -f /home/yourname/rsync_202XMMDD.log
コードは注意してご使用ください。
初回はデータ量が多いと思いますが、無事に完走することを祈っています!
転送するファイルの総量(GB単位など)はかなり大きいのでしょうか?
