要するに：フォルダの日付ではなく、バックアップ内で最も新しいファイルの日付を確認してください。フォルダのタイムスタンプは、バックアップの完了とは関係のない理由で変わります。
中で最も新しいファイルが昨日より古ければ、ツールが何と言っていようと、バックアップは実行されていません。
バックアップのアドバイスのほとんどは、間違った災害を想定しています。ディスクの故障、ノートパソコンの盗難、洪水といった劇的な災害です。それらはまれで、誰もが理解しています。
よくある原因は退屈なものです。別のものを挿すためにドライブを外し、戻さなかった。停電後に NAS が再起動し、共有が再マウントされなかった。ジョブの予定時刻にノートパソコンが毎晩閉じられていて、それが 1 か月続いた。1 年間問題なかったログは誰も読まないので、スクリプトが誰にも読まれないエラーで終了していた。
どのケースでも、何も壊れていません。人が見る場所のどこにもエラーは出ません。バックアップフォルダはまだあり、ファイルでいっぱいで、サイズも正しいままです。変わったのは、新しくならなくなったことだけで、システムの中にそれを伝える価値があると考えるものは何もありません。
これをバックアップの保存先に向けます。中のどこかで最も最近変更されたファイルを見つけ、その日付を表示します。
find /Volumes/Backup -type f -print0 | xargs -0 stat -f '%m %N' | sort -rn | head -5最初の列は Unix タイムスタンプです。直接読むには：
find /Volumes/Backup -type f -newermt '-2 days' | head何も表示されなければ、2 日間何も書き込まれていません。それが答えで、ファイルそのものの性質なので、どんな状態画面よりも信頼できます。
Time Machine の場合：
tmutil latestbackupこれは最新のスナップショットのパスを、名前に日付を含めて表示します。1 つもなければエラーになります。
つい Finder でバックアップフォルダを見て「変更日」の列を読みたくなります。その数字は思っているものとは違います。
ディレクトリの変更日時は、中に何かが追加または削除されたときに変わり、中のファイルの内容が変わったときには変わりません。Spotlight のインデックス作成、.DS_Store の書き換え、ウイルス対策ソフトのスキャン、クラウドクライアントによる自分のメタデータの更新。どれも、古いバックアップフォルダを今朝書き込まれたかのように見せることがあります。
記録になるのは中のファイルです。フォルダではありません。
StartCalendarInterval を使った launchd ジョブは、Mac がスリープ中は実行されず、指定しない限りあとで追いかけて実行することもありません。深夜 0 時に閉じたノートパソコンでは、深夜 0 時のバックアップは一度も実行されていません。launchd のジョブは文句をファイルに書き込み、それを知っているのはそのファイルだけです。自分でやるなら、解決策はデッドマンスイッチです。バックアップが行われなかったときに文句を言う仕組みです。これは失敗とは別の出来事で、上のケースをカバーできるのは前者だけです。
最も簡単なのは、最も新しいファイルの経過時間を確認し、古すぎれば声を上げるジョブです。
if [ -z "$(find /Volumes/Backup -type f -newermt '-2 days' 2>/dev/null | head -1)" ]; then
osascript -e 'display notification "No backup in two days" with title "Backup"'
fiこれはバックアップとは別の独自のスケジュールで実行し、バックアップのスケジュールが壊れても、それを監視するものまで壊れないようにします。この最後の点を間違える人が多いのです。バックアップジョブの中で実行する確認は、バックアップジョブが実行されなかったことを報告できません。
本当に欲しいのは、「ない」こと自体がアラームになり、ツールが欠けているものの名前を挙げてくれることです。
Copy Shelter はそれを前提に作られています。各保存先に最後に書き込んだ日時と最後に確認した日時を記録し、うまくいったバックアップがないまま 7 日たつと知らせます。保存場所の名前を挙げるので、「引き出しのドライブを 8 月 14 日以来見ていません」のように伝わります。さらにバックアップを読み戻し、各ピースを保存時のハッシュと照合するので、実行はされているのに読めないものを出力しているバックアップも検出できます。これはこのページの一歩先の障害です。
表示されるスコアは、最近検証されたものだけを数えます。実行されていないバックアップは持っているバックアップではなく、数字がそれを示します。
そうする必要はないはずです。それがこのページの要点です。手作業でする確認は、いずれやめてしまう確認で、たいてい設定から 3 週間ほどでやめます。「ない」ことを知らせるアラームを自動化し、手作業での確認は、それが知らせてきたときにすることにしましょう。
役には立ちますが、限界があります。Time Machine は 10 日間バックアップが完了しないと警告しますが、その通知は閉じやすく、気にしなくなりやすいものです。また、完了したバックアップが読めないことも教えてくれません。ローカルディスクでは確認しないからです。
それはアクセス許可のケースで、すべての状態表示が成功と言うので、より厄介です。保存先のファイル数を元の場所のファイル数と比べてください。何万ものファイルがあるはずのバックアップに 40 個しかなければ、macOS がフォルダへのアクセスを拒否しており、ジョブにはそれが伝わっていません。
形は違いますが、あります。同期クライアントはサインアウトしたり、容量の上限に達したり、自ら一時停止したりし、それを知らせるバッジは見ていないメニューバーの小さなアイコンです。ファイルも元の場所にそのまま残るので、何もおかしく見えません。
ほぼそのとおりです。異なる理由で故障する 2 つの保存先を個別に確認するほうが、1 つをどれだけ監視するよりも価値があります。監視はコピーが失われたことを教えてくれます。2 つ目のコピーがあれば、それは問題になりません。3-2-1 ルールをご覧ください。
関連：バックアップが実際に読めるか確認する、3-2-1 ルール。