Re: TM backups of a restored drive

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