Jawaban singkat: periksa tanggal file terbaru di dalam cadangan, bukan tanggal folder. Stempel waktu folder berubah karena alasan yang sama sekali tidak terkait dengan selesainya pencadangan.
Jika file terbaru di dalamnya lebih lama dari kemarin, cadangan tidak berjalan, apa pun yang dikatakan alatnya.
Sebagian besar saran tentang cadangan membahas bencana yang salah. Saran itu membayangkan bencana dramatis: disk mati, laptop dicuri, banjir. Hal-hal itu jarang terjadi dan semua orang memahaminya.
Penyebab yang umum itu membosankan. Drive dicabut untuk memberi tempat bagi hal lain dan tidak pernah dikembalikan. NAS menyala ulang setelah listrik padam dan share tidak terpasang kembali. Laptop ditutup tepat saat tugas dijadwalkan, setiap malam, selama sebulan. Skrip keluar dengan kesalahan yang tidak dibaca siapa pun karena tidak ada yang membaca log yang baik-baik saja selama setahun.
Dalam setiap kasus itu, tidak ada yang rusak. Tidak ada kesalahan yang muncul di tempat yang dilihat orang. Folder cadangan masih ada, masih penuh file, masih berukuran benar. Satu-satunya yang berubah adalah folder itu berhenti diperbarui, dan tidak ada bagian sistem yang menganggap itu layak disebutkan.
Arahkan ini ke tujuan cadangan Anda. Perintah ini menemukan file yang paling baru diubah di mana pun di dalamnya dan mencetak tanggalnya:
find /Volumes/Backup -type f -print0 | xargs -0 stat -f '%m %N' | sort -rn | head -5Kolom pertama adalah stempel waktu Unix. Untuk membacanya langsung:
find /Volumes/Backup -type f -newermt '-2 days' | headJika tidak ada yang tercetak, tidak ada yang ditulis dalam dua hari. Itulah jawabannya, dan lebih dapat dipercaya daripada layar status mana pun, karena itu sifat dari file itu sendiri.
Khusus untuk Time Machine:
tmutil latestbackupyang mencetak jalur snapshot terbaru, dengan tanggal di namanya, atau kesalahan jika tidak ada.
Naluri pertama adalah melihat folder cadangan di Finder dan membaca kolom Tanggal Diubah. Angka itu bukan seperti yang Anda kira.
Waktu modifikasi direktori berubah saat sesuatu ditambahkan atau dihapus darinya, dan tidak berubah saat isi file di dalamnya berubah. Pengindeksan Spotlight, .DS_Store yang ditulis ulang, pemindai antivirus, klien cloud yang menyentuh metadatanya sendiri: semua ini dapat membuat folder cadangan yang basi terlihat seperti baru ditulisi pagi ini.
File di dalamnya adalah catatannya. Foldernya bukan.
launchd dengan StartCalendarInterval tidak berjalan saat Mac tidur, dan tidak menyusul setelahnya kecuali Anda memintanya. Laptop yang ditutup pada tengah malam punya pencadangan tengah malam yang tidak pernah sekali pun terjadi.launchd menulis keluhannya ke file, dan file itu satu-satunya yang tahu.Jika Anda melakukannya sendiri, solusinya adalah dead man's switch: sesuatu yang mengeluh saat pencadangan tidak terjadi. Itu peristiwa yang berbeda dari pencadangan yang gagal, dan hanya yang pertama yang mencakup kasus-kasus di atas.
Versi paling sederhana adalah tugas yang memeriksa usia file terbaru dan berteriak jika terlalu lama:
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"'
fiJalankan itu dengan jadwalnya sendiri, terpisah dari pencadangan, agar jadwal pencadangan yang rusak tidak ikut merusak hal yang mengawasinya. Poin terakhir itulah yang sering keliru: pemeriksaan yang berjalan di dalam tugas cadangan tidak dapat melaporkan bahwa tugas cadangan tidak berjalan.
Yang sebenarnya Anda inginkan adalah ketiadaan itu sendiri menjadi alarm, dan alat menyebut nama hal yang hilang.
Copy Shelter dibangun di atas hal itu. Copy Shelter mencatat kapan setiap tujuan terakhir ditulisi dan terakhir diperiksa, dan bersuara setelah tujuh hari tanpa pencadangan yang berhasil. Copy Shelter menyebut nama lokasinya, sehingga Anda mendapat "drive di laci belum terlihat sejak 14 Agustus". Dan karena Copy Shelter membaca ulang cadangan dan memeriksa setiap bagian terhadap hash tempat ia disimpan, cadangan yang berjalan tetapi menghasilkan keluaran yang tidak terbaca juga tertangkap, yaitu kegagalan satu langkah di luar topik halaman ini.
Skor yang ditampilkannya hanya menghitung apa yang baru-baru ini diverifikasi. Cadangan yang tidak berjalan bukanlah cadangan yang Anda miliki, dan angkanya menyatakan hal itu.
Seharusnya Anda tidak perlu melakukannya. Itulah inti halaman ini: pemeriksaan yang Anda lakukan secara manual adalah pemeriksaan yang akan Anda hentikan, biasanya sekitar tiga minggu setelah Anda menyiapkannya. Otomatiskan alarm ketiadaan, dan jadikan pemeriksaan manual sebagai hal yang Anda lakukan saat alarm itu memberi tahu.
Itu membantu, tetapi terbatas. Time Machine memperingatkan setelah tidak menyelesaikan pencadangan selama sepuluh hari, dan notifikasinya mudah diabaikan dan mudah tidak lagi diperhatikan. Time Machine juga tidak bisa memberi tahu bahwa cadangan yang berhasil diselesaikannya tidak terbaca, karena pada disk lokal Time Machine tidak memeriksa.
Itu kasus izin, dan lebih buruk karena setiap indikator status menunjukkan sukses. Bandingkan jumlah file di tujuan dengan jumlah di sumber. Jika cadangan yang seharusnya berisi puluhan ribu file hanya berisi empat puluh, macOS menolak akses ke folder dan tugasnya tidak diberi tahu.
Dengan cara berbeda, dan ya. Klien sinkronisasi keluar sendiri, mencapai kuota, dan menjeda dirinya sendiri, dan lencana yang akan memberi tahu Anda hanyalah ikon kecil di bar menu yang tidak Anda lihat. File-file juga tetap berada di tempatnya, sehingga tidak ada yang terlihat salah.
Sebagian besar, ya. Dua tujuan yang gagal karena alasan berbeda, diperiksa secara terpisah, lebih berharga daripada pemantauan sebanyak apa pun pada satu tujuan. Pemantauan memberi tahu bahwa salinan hilang; salinan kedua berarti hal itu tidak menjadi masalah. Lihat aturan 3-2-1.
Terkait: memeriksa apakah cadangan benar-benar bisa dibaca, dan aturan 3-2-1.