Jawaban singkat: catat hash saat Anda menulis file, dan bandingkan nanti. Jika hash berbeda dan tidak ada yang mengedit file itu, byte-nya berubah tanpa sepengetahuan Anda.
Tidak ada yang lain yang menemukan ini. Disk dengan kerusakan diam-diam lolos Pertolongan Pertama, melaporkan SMART yang sehat, dan terpasang dengan sempurna.
Penyimpanan itu fisik. Domain magnetik di disk yang berputar melemah. Muatan bocor dari sel memori flash, lebih cepat saat panas dan lebih cepat lagi saat drive lama tidak diberi daya. Kabel bisa menjatuhkan satu bit saat transit. Firmware punya bug.
Drive memperbaiki sebagian besar hal ini sendiri, dengan kode koreksi kesalahan dan dengan memindahkan sektor yang mulai rusak. Kerusakan yang penting adalah bagian yang lolos dari itu: pembacaan yang menghasilkan byte berbeda dari yang ditulis, dan melaporkan sukses.
Namanya diperdebatkan orang. Ada yang menyebutnya bit rot, ada yang menyebutnya kerusakan data diam-diam, ada yang menyebutnya degradasi data. Untuk keperluan kita semuanya sama: file berbeda dan tidak ada yang memberi tahu.
Inilah bagian yang layak dipahami, karena menjelaskan mengapa setiap alat yang akan Anda pakai adalah alat yang salah.
cp dan Finder membaca byte dan menulis byte. Jika pembacaan menghasilkan byte yang salah, keduanya dengan setia menulis byte yang salah.Jadi posisi yang jujur adalah: Mac Anda tidak punya mekanisme yang akan memberi tahu Anda. Gejala pertama adalah foto dengan pita sampah di tengahnya, arsip yang tidak mau terbuka, atau video yang berhenti di tengah jalan.
Jarang per file, dan tidak jarang di koleksi besar dalam waktu lama, yang merupakan kasus yang menjadi alasan adanya cadangan. Dua hal yang meningkatkan peluangnya secara nyata:
Alasan hal ini lebih penting di cadangan daripada di disk kerja Anda adalah file kerja dibuka, dan file rusak yang dibuka adalah kerusakan yang sudah Anda temukan. Cadangan ditulis sekali dan tidak pernah dibaca, artinya kerusakan di cadangan ditemukan pada hari Anda membutuhkan cadangan itu.
Catat apa yang Anda tulis:
cd /Volumes/Backup
find . -type f -exec shasum -a 256 {} \; > ~/backup-hashes.txtLalu, berbulan-bulan kemudian, tanyakan apakah masih sama:
cd /Volumes/Backup
shasum -a 256 -c ~/backup-hashes.txt | grep -v ': OK$'Apa pun yang tercetak adalah file yang byte-nya sudah berubah. Jika Anda tidak mengeditnya, itulah jawabannya.
Dua catatan praktis. Simpan file hash di tempat selain drive yang dijelaskannya, atau Anda akan kehilangan keduanya sekaligus. Dan ini memakan waktu selama membaca seluruh drive, jadi jadwalkan di malam hari.
Semua hal di atas adalah alasan aplikasi ini ada dalam bentuknya sekarang. Aplikasi ini menyimpan setiap bagian cadangan di bawah hash isinya, lalu membaca ulang cadangan secara terjadwal dan memeriksa setiap bagian terhadap hash tempat ia disimpan.
Karena itu ketidakcocokan adalah bukti: byte-nya bukan byte yang ditulis, dan tidak ada tafsiran yang membuat hal itu baik-baik saja. Bagian yang terhapus di bawah cadangan dilaporkan hilang. Dan skor di layar utama hanya menghitung apa yang baru-baru ini diverifikasi, itulah sebabnya skornya lebih rendah daripada yang diharapkan orang dan justru itulah intinya.
Memiliki lokasi kedua lebih penting di sini daripada di bagian mana pun di situs ini. Kerusakan di satu salinan hanyalah ketidaknyamanan jika ada dua, dan merupakan akhir dari file itu jika hanya ada satu.
Tidak. Pertolongan Pertama memeriksa struktur sistem file, bukan isi file Anda. Drive dengan file yang diam-diam rusak lolos dengan bersih, dan justru itulah yang membuat masalah ini seperti adanya.
Tidak untuk ini. SMART melaporkan kesalahan yang disadari drive lalu diperbaiki atau dipindahkan. Kerusakan diam-diam justru yang tidak disadarinya. Tetap layak diperiksa untuk drive yang mulai rusak, yang merupakan masalah lain dan lebih terlihat.
APFS memberi checksum pada metadatanya sendiri, bukan data file Anda. ZFS dan Btrfs memberi checksum pada isi file dan dapat memperbaiki dari salinan redundan, dan keduanya tidak tersedia sebagai volume boot atau eksternal macOS biasa. Celah itulah alasan pemeriksaan di tingkat aplikasi layak dimiliki.
Cukup sering sehingga salinan buruk ditemukan selagi salinan yang baik masih ada. Per kuartal wajar untuk arsip; bulanan jika itu satu-satunya salinan sesuatu yang tak tergantikan. Jawaban yang tepat adalah apa pun yang benar-benar tidak akan Anda lewatkan, dan itu menjadi alasan agar dilakukan otomatis.
Tidak. Verifikasi memberi tahu Anda bahwa salinan rusak. Verifikasi tidak dapat mengembalikan file. Deteksi hanya berguna jika ada salinan kedua untuk dipulihkan, dan itulah seluruh argumen untuk aturan 3-2-1.
Terkait: cara memeriksa apakah cadangan bisa dibaca, format repositori, dan aturan 3-2-1.