AntonRang Posted January 29, 2014 Report Share Posted January 29, 2014 This started out as a post about how I was very happy with Retrospect — and actually, I’m still not too unhappy with it, but much less at the moment than I was a few minutes ago, because my restored data isn’t exactly what was backed up. One of my systems died overnight, and after an attempt to restore from a Time Machine backup failed to create a bootable system, I did a bare-metal restore to a second machine, using Retrospect and Target Disk Mode. The restore took a long time (15 hours or so), but I was able to boot the system and everything looked great. Then, as I was reading a post here and wanted to refer to a SCSI PDF document, I discovered that one of my documents wasn’t readable. Checking the time machine backup, it looked fine, but the restored copy was bad. After investigating a bit, it appears that Retrospect (10.5.0) managed to restore my files, but seems to have copied the resource fork on top of the data fork for at least some of them. :-( If the resource fork contained AAA and the data fork contained 123456, then the file now contains AAA456, though it *also* has a good copy of the resource fork. This is, obviously, a problem, though I can likely rsync the affected files from my time machine backup, at least. There may not be very many affected files, either. I don’t know if this would affect a restore through the client; it may be only when restoring to a local disk. I’m also not sure if it affected all files (no, it didn’t; I’ve found that most seem to have a properly restored resource fork, which makes me wonder what’s special about the affected files). So this is a bug report — that there’s some circumstance in which a resource fork is restored both as a resource fork and on top of a data fork — and a request, that there be an option during restore to verify file checksums. (Maybe that’s already there and I missed it; I didn’t see it in the wizard, at least.) And it’s also a thank you — because even with this bug, Retrospect has restored my machine to working order, which Time Machine utterly failed at. (Though I may use the Time Machine backup to address any files affected by this bug; proving that it’s good to have multiple backup strategies.) Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted January 29, 2014 Report Share Posted January 29, 2014 There may be a connection between Time Machine's failure and Retrospect's failure. Which version(s) of Mac OS were you running, on both the Retrospect server as well as the destination client (the one who had the target mode disk connected)? How was the destination disk formatted? Was is newly formatted? What if you restore the problematic files from Retrospect and NOT using target disk mode? Quote Link to comment Share on other sites More sharing options...
AntonRang Posted January 29, 2014 Author Report Share Posted January 29, 2014 Some more details and thoughts… My Retrospect backup system is running 10.7.5; my client is currently running 10.9.1, though it wasn’t involved in the restore since this was target disk mode. I realized I don’t have good reason to believe that it’s the restore, rather than the backup, which is at fault. Since the affected files I’ve found so far are all quite old, this means that it could be whatever version of Retrospect was available in November 2012 (when the original full backup to this media set was performed) that was at fault, backing up a client on Mac OS X 10.8.x. If I get the time & a spare disk, I may try restoring from a backup set which has been reset more recently to see if it’s good. Quote Link to comment Share on other sites More sharing options...
AntonRang Posted January 29, 2014 Author Report Share Posted January 29, 2014 There may be a connection between Time Machine's failure and Retrospect's failure. It’s possible, though the Time Machine failure seems to be more an issue that it didn’t back up quite everything, which seems to be a fairly common failure mode. :-( Which version(s) of Mac OS were you running, on both the Retrospect server as well as the destination client (the one who had the target mode disk connected)? How was the destination disk formatted? Was is newly formatted? 10.7.5 on server, 10.9.1 on client (as noted in my update). The destination was newly formatted on the 10.7.5 system as a Mac OS X Extended (journaled) file system. What if you restore the problematic files from Retrospect and NOT using target disk mode? I’ll give that a try when I get the chance. :-) If they still seem bad, I’ll try from another media set. Thanks! Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted January 29, 2014 Report Share Posted January 29, 2014 Perhaps the files were bad already before the Retrospect backup? Files with resource forks isn't handled when stored on a file server using SMB. (AFP is needed). Also ftp transfer may corrupt the file(s). Quote Link to comment Share on other sites More sharing options...
Don Lee Posted January 29, 2014 Report Share Posted January 29, 2014 Ugh! How do you know what files are affected? Did you do a complete compare with Time machine? If you run any experiments to explore, I'd be interested in whether this is a problem in the media set (wrong in the backup set), the type of restore (files or "whole disk"), or the target (client or local disk). I hope it's not just a class of files that can't be handled properly, and is some combination of circumstances that messes up the particular restore. If the latter, I can watch out for it, and work around it if I hit it. Quote Link to comment Share on other sites More sharing options...
AntonRang Posted January 30, 2014 Author Report Share Posted January 30, 2014 Ugh! How do you know what files are affected? Did you do a complete compare with Time machine? If you run any experiments to explore, I'd be interested in whether this is a problem in the media set (wrong in the backup set), the type of restore (files or "whole disk"), or the target (client or local disk). I hope it's not just a class of files that can't be handled properly, and is some combination of circumstances that messes up the particular restore. If the latter, I can watch out for it, and work around it if I hit it. I was very lucky in that I was reading the forum posts here and ran into the desire to look up an ASC/ASCQ pair in reply to one — and, out of the tens of thousands of technical papers I’d restored, it appears that the 6 affected were all SCSI-related, of which one was the SPC document I was looking for. Perhaps that's because few documents have a resource fork any more, but I found many other files with resource forks that were fine, so there's something odd here. I've been doing a complete comparison with time machine, but diff --recursive doesn't deal well with symbolic links. Some variant of that, though, will be how I verify things in the end. I'll be experimenting with some different restores, but the media set is pretty large (1.5 TB), with 1.5 million files or so on this volume, so the selection process isn’t very fast on my 7-year-old Mac Mini. :-) I’m also curious whether the same problem affected more than one media set (I back up to a rotating set of 3, of which one gets periodically reset so as not to require grooming). Quote Link to comment Share on other sites More sharing options...
AntonRang Posted January 30, 2014 Author Report Share Posted January 30, 2014 I'll be experimenting with some different restores First finding: It seems to be a bug which affects restore; it’s not (only?) an issue in the media set. Second finding: It’s usually, but not always, the same files. (Very strange.) I restored the most-affected directory (SCSI standards, there’s some irony there) to the Retrospect server’s local disk. With its subdirectories, it contains 108 files, including 58 PDF files, 10 of which have resource forks. Of those, 6 were restored incorrectly on my original system. The same 6 were restored incorrectly on the server — but so was one more, also with the symptom that its data fork had been overwritten with the contents of the resource fork (which had also been saved as a resource). The affected files don't seem to have anything in common which differentiates them from the 40-odd files which are restored properly on both systems; their size varies from 200 KB to 4 MB, the resource forks are all around 48 KB (but so are those for the unaffected files with resource forks), etc. Quote Link to comment Share on other sites More sharing options...
AntonRang Posted January 30, 2014 Author Report Share Posted January 30, 2014 Restoring that directory from another media set to the server disk results in the same seven files being incorrect. Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted January 30, 2014 Report Share Posted January 30, 2014 What about restoring the same seven files from Time Machine? Quote Link to comment Share on other sites More sharing options...
AntonRang Posted January 31, 2014 Author Report Share Posted January 31, 2014 They're all fine on the Time Machine disk … And at least one restored properly before, which is interesting too :-) Quote Link to comment Share on other sites More sharing options...
Lennart_T Posted January 31, 2014 Report Share Posted January 31, 2014 They're all fine on the Time Machine disk … And at least one restored properly before, which is interesting too :-) That is not what I meant: I meant actually restoring from the TM disk to the same location that Retrospect restores to. In the last sentence, do you mean restore from TM or restore from Retrospect? Quote Link to comment Share on other sites More sharing options...
Don Lee Posted February 1, 2014 Report Share Posted February 1, 2014 Gee, it sure would be nice to know the format of the media set so we could just look to see if the data is correct rather than running time consuming experiments....... :-\ Quote Link to comment Share on other sites More sharing options...
AntonRang Posted February 6, 2014 Author Report Share Posted February 6, 2014 That is not what I meant: I meant actually restoring from the TM disk to the same location that Retrospect restores to. In the last sentence, do you mean restore from TM or restore from Retrospect? Ah, OK. I just did a Time Machine restore (before I was just using “cp”), and got back the original files (e.g. non-corrupted PDF format). When I said “one restored properly before”, I meant from Retrospect — when I restored my entire computer, 6 files were damaged after the restore had finished. When I restored the affected folder (a hierarchy containing about 100 PDF files) onto another disk from the same media set, 7 files were damaged. (Since they’re PDF files, it’s really easy to tell when they’re bad.) Quote Link to comment Share on other sites More sharing options...
AntonRang Posted February 6, 2014 Author Report Share Posted February 6, 2014 Gee, it sure would be nice to know the format of the media set so we could just look to see if the data is correct rather than running time consuming experiments....... :-\ Or at least have a command-line tool which could be used to inspect them … 1 Quote Link to comment Share on other sites More sharing options...
Don Lee Posted February 7, 2014 Report Share Posted February 7, 2014 Or at least have a command-line tool which could be used to inspect them … ... even a "verify" operation that provided more detail. (My experience with "verify" does not inspire confidence. I have seen it go through clean on known-corrupt media sets, and I don't know that it has ever given me more useful information than what I would have gotten from trying to read the set with "dd". ) Quote Link to comment Share on other sites More sharing options...
Don Lee Posted October 15, 2014 Report Share Posted October 15, 2014 Has this been fixed in latest version(s)? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.