Thanks, Chris, for the very detailed writeup. I installed smartmontools via Macports, it works on the boot drive (Seagate), but on my external drives (Maxtor and G-Drive) it comes up with the same 'unsupported' error. Guess they don't support SMART. $ sudo smartctl -a /dev/disk2s1 smartctl 5.42 2011-10-20 r3458 [x86_64-apple-darwin10.8.0] (local build) Smartctl open device: /dev/disk2s1 failed: Operation not supported by device
The external drives are not the boot drive. I've been using the new drive for a day now, working on the same projects as before, and I've not come across any files that appear damaged or truncated. Everything seems kosher, but I guess it depends on what TM does when it gets a disk I/O error - skip the backup of that particular file? I did run Disk Warrior on the suspect drive before doing the asr copy, and it found nothing, a result which surprised me. Perhaps DW's rebuilding of the drive index was the cause of TM's full backup? As much as I hate to, I guess I could zero the TM drive and start over with it. - Nate On Mar 26, 2012, at 8:24 PM, Chris Murphy wrote: > I previously wrote: > >> To answer your question, asr does sector copies only if you've booted from >> another volume, such that the state of the source volume you're copying is >> not changing. If you've booted from the source disk, its state changes >> constantly so a sector copy isn't possible, it has to do a file copy. The >> resulting volume has a different GUID, and a new file system. > > And that also includes new inodes. And Time Machine makes heavy use of hard > links, which depend on inodes. That alone would be enough to require a new, > from scratch, Time Machine backup. > > And then there's the way the file system tracks changes using mds and file > system metadata, so it knows what files to incrementally backup. Chances are, > when asr did its file copy, all of that information was reset. So that also > could be a cause. > > But I suspect backupd saw that the new disk had a new GUID and from that > determined it was going to do a full backup of everything - most efficient > way to go about it. > > I suggest triage: open the most important files, every single one of them, > and see if they contain any symptoms of corruption. Top on the list, they > can't be opened by their creating application. Next, partial corruption which > you may find as formatting weirdness, or entire pages that have garbled > content. Images are usually more obvious when they've been corrupted. > > Chris Murphy > _______________________________________________ > MacOSX-admin mailing list > [email protected] > http://www.omnigroup.com/mailman/listinfo/macosx-admin _______________________________________________ MacOSX-admin mailing list [email protected] http://www.omnigroup.com/mailman/listinfo/macosx-admin
