What is the easiest way to restore an OS X boot hard drive?

[albert]

My OS 10.4.7 system disk really died. It shorted out the computer and I thought it was something more serious. I now have a new blank hard disk. What would be the easiest way to restore? I assume I should run a full restore to an external hard disk, and then install a fresh copy of OS 10.4 and use the transfer from previous disk/computer option that Apple now has. Is this the best way? I certainly don't want to drag everything back manually. thanks

[waltr]

hi albert,

 

if you backed up the whole disk and you have an external drive you can boot from (with Retrospect on it) then i would boot from the external and do a full Restore. then you boot to the internal drive, Voila!

[rhwalker]

The best way, in my opinion, is the way suggested in the Retrospect manual:

 

First to an install from your Mac OS X install disk, then bring the install forward with OS updates and security patches so it is at the same level as the OS used when you made the backup. Then use Retrospect to do a restore of everything on top of that. A full explanation of why would be a lengthy treatise, but it has to do with backing up busy files. See also this thread here in the Retrospect forums:

Is a Duplicate an exact duplicate?

 

Russ

[CallMeDave]

Quote:

---

The best way, in my opinion, is the way suggested in the Retrospect manual

 

---

 

blech.

 

> A full explanation of why would be a lengthy treatise, but it has to do with backing up busy files.

 

The Backup Set already exists, so limitations as to what got backed up are not relevant to a discussion on the best way to Restore.

 

Although albert did not share what Type of Backup Set contains the data, nor is there confirmation that the entire boot volume was backed up, I have to go with waltr's suggestion as the best way to put the contents of a Backup Set back onto a new, empty drive.

 

However, Albert's idea is actually quite thought provoking, in that it also addresses some of the concerns that Russ expresses about backup quality.

 

Doing the Restore to an empty off-line drive, installing OS X on the new internal drive, then using Migration Assistant to move user data would insure that the base install is clean, no matter how the original backup was done.

 

Of course, some non-user items, such as kext files that might have been installed, might not make it over to the new drive. But it's still worth considering.

 

Dave

[rhwalker]

Quote:

---

Quote:

---

The best way, in my opinion, is the way suggested in the Retrospect manual

 

---

blech.

 

> A full explanation of why would be a lengthy treatise, but it has to do with backing up busy files.

 

The Backup Set already exists, so limitations as to what got backed up are not relevant to a discussion on the best way to Restore.

 

---

Glad to see you are recovering from your recent head injury, Dave. However I believe you missed my point, because limitations on what got backed up are relevant to a discussion on the best way to Restore. The reason that Retrospect's manual suggests restoring on top of a clean install is that busy files, pehaps even some busy files critical to the operation of the OS, aren't backed up by Retrospect. A clean install of the same version of the OS will have those files necessary for operation. Restoring on top of that will update with whatever is in the backup set, giving you the best possible restore - those files that are in the backup set will be in the restored set; those files missing from the backup set will hopefully be present from the clean install.

 

Now, for correctly written programs, there shouldn't be an issue. Application code is paged from the app and won't be busy (it's read only). Preference files, if done correctly, should be opened read-only and so shouldn't be busy. But there's always the possibility that some summer help programmer got code out the door with poor QA, such that some critical file didn't get backed up because it was busy. I agree with you that other issues (bad selectors, etc.) that might produce an incomplete backup can't be helped at this point, but I still believe that a restore on top of a clean install would give the best chance of success.

 

A migration approach is an interesting strategy that I hadn't considered, and might fix some latent problems existing prior to the backup with a fresh start.

 

Russ

[CallMeDave]

Quote:

---

I still believe that a restore on top of a clean install would give the best chance of success.

 

---

 

I suppose that I would too, if I had complete trust in the Live Restore process. I don't.

 

The fact that the user is obligated to start with a machine with system software exactly matching the level on the Backup Set, even though there is no way to _know_ what that level is after the fact scares me.

 

What is a critical machine's disaster recovery scenero supposed to be? A full Restore to a temporary offline drive, followed by a restart into that drive allowing for an inspection of the syste/security level, so the information can be used for the actual Live Restore? Or maybe just write down any new Software Update activity on the tape label?

 

I've looked at a lot of log files of full backups, and generally can account for all the compare errors that show up, especially for any files that are not copied at all. I have more confidence that the Apple provided parts of a Mac OS X machine is capable of being backed up while running then I do of Retrospect correctly merging a Backup Set to a new install.

 

But that's just me.

[jwarthman]

Coincidentally, I'm wrestling with a similar issue.

 

My boot drive became corrupt, and I had confidence that I could put things back the way they were using Retrospect. (I've done it several times before.) But for some reason, this time isn't going so smoothly.

 

I should add that I'm running Retrospect 6.1.126 under OSX 10.4.6. My backup set is on an external Firewire drive, and I'm running from a separate drive that has Retrospect installed.

 

First attempt, I reformatted the corrupt drive, re-installed the OS and applied updates. (One anomaly, I think I didn't specify exactly the same user name when the installer set up my account). I did the restore using "Replace corresponding files", but when I restarted I could NOT login! Oops! Probably an operator headspace malfunction.

 

Second attempt, after reading through the user guide, it seemed like, as long as I can boot on a volume that has Retrospect (similar to the emergency Retrospect CD), I can just do the restore. I did, using "Restore entire disk", and it seemed to go well, except that when I boot on the restored volume, many preferences are gone!!! For instance, my Dock is no longer customized, and neither is the menu bar.

 

So my first question is, what things could cause the Dock et al. to revert to some default condition? (In the past, the restore has restored my Dock.)

 

Second question, won't a "Restore Entire Disk" overwrite ALL of the OS files, and delete whatever isn't part of the backup set? If so, what's the point of re-installing OSX first? So, if I've reinstalled OSX, exactly which restore strategy should I use (I'm booted from a separate volume that has Retrospect)?

 

I'm in the midst of trying to get things back to normal, so I really appreciate your feedback!

 

Enjoy,

 

-- Jim

[smartin]

 

Hi:

For what it's worth, when I need to do full restores in OSX, I attach the computer to the backup system via firewire target disk mode, and do a full restore to the formatted drive. The only issue with this is I then need to run Disk Warrior to bless the system volume. I suspect a CLI command at single user mode might be ableto do the same thing, but Disk Warrior works for me.

I've done this trick about 10 times, and have never had any problems with the end computers, but your milage may vary. As I read a bit further, i see your backing up to a firewire drive. Apple warns not to do external firewire disk mode with another firewire drive attached, so I'm not sure if this would work for you or not.

 

Dave, I've wondered the exact same thing as you. How do you know what OS version a user is running? Ask the user? Our users can tell you if they are running on a mac or a PC about half the time, so asking them if they are running 10.4.7 or 10.4.6 is not an option. Plus, the windows machines get forced automagic upgrades, we don't do that for the macs.

-s

[CallMeDave]

Quote:

---

won't a "Restore Entire Disk" overwrite ALL of the OS files, and delete whatever isn't part of the backup set?

 

---

 

No.

 

Retrospect will Match files in the Destination that it sees as being identical to the ones in the Source. Matched files will be left in place.

 

But I'm just not sure how well this works. I'm not 100% certain that the program even tries to match files in /System or /private. I'm not certain that some Apple system files don't match Retrospect's criteria, but actually contain different information.

 

The idea of installing an OS first is for when you have to boot into that OS; what you're doing does not require that step, and I wouldn't recommend it.

[jwarthman]

Quote:

---

Retrospect will Match files in the Destination that it sees as being identical to the ones in the Source. Matched files will be left in place.

 

---

 

Dave,

Thanks for the clarification.

 

 

Quote:

---

The idea of installing an OS first is for when you have to boot into that OS; what you're doing does not require that step, and I wouldn't recommend it.

 

---

 

I understand. And yet, when I've done this in the past it has worked flawlessly. But yesterday when I tried just reformatting the drive then restoring from the backup, weird things happened.

 

I'd still appreciate some thought as to what might not have been (properly) restored that would cause my Dock to revert to default.

 

Thanks!

 

-- Jim

[CallMeDave]

Quote:

---

I'd still appreciate some thought as to what might not have been (properly) restored that would cause my Dock to revert to default.

 

---

 

~/Library/Preferences/com.apple.dock.plist

[jwarthman]

Dave,

Thanks much!

 

Okay, for a bit more clarification... The Retrospect User Guide says, on p. 53:

 

Quote:

---

Replace corresponding files copies the marked files to the destination volume into the same folders. Corresponding files are overwritten, even if they are newer. Retrospect leaves files untouched if they are identical to files marked for restore or if the file names do not match those marked for restore.

 

---

 

At first blush this seems clear. But upon closer scrutiny, don't the phrases "corresponding files are overwritten" and "Retrospect leaves files untouched if they are identical" seem to conflict?

 

If someone knows what's really happening, I'd love to hear about it!

 

Thanks!

 

-- Jim

[Mayoff]

If an identical file already exists on the HD drive in a corresponding path then the file is not restored because it already exists on the drive.

[CallMeDave]

I think the wording Corresponding files are overwritten, even if they are newer is to explain the fact that non-identical files will be overwritten, no matter if they are older then the ones on the Backup Set or if they are newer. In this manner, Retrospect is _not_ a volume synchronization tool.

[jwarthman]

 

First of all, thanks *very much* to the folks here, and to Dr. Smoke on the Apple forums for pointing me in the right direction!

 

* I booted on my "backup system".

 

* Great news: I looked at my backup set and found many versions of the .plist files (loginwindow.plist and com.apple.dock.plist).

 

* I restored the most recent versions using Restore > Search for Files & Folders > Replace Corresponding Files.

 

* I restarted, and my dock & startup applications were back to normal!

 

Again, thank you, thank you, thank you!

 

But now to the troubling questions.

 

I mentioned that my dock and my startup items were two issues that I noticed right away after restoring my hard drive. I've just demonstrated that the backup *does* contain the relevant .plist files, and I was able to correct the problem. The key questions now are:

 

1. Why didn't those files get restored the first time 'round?

 

2. What other files haven't been restored due to the same factor(s)?

 

I really, really want to identify the root cause of this problem, then perform one more *successful* restore so I don't need to worry about the integrity of my system, and about potentially lost data.

 

So, I'm open to further suggestions regarding why these .plist files (and who-knows-what other files) didn't get properly restored. Or perhaps they DID get restored, but for some reason couldn't be used and got replaced with generic default versions. But then, my partial restore tonight succeeded....

 

*sigh*

 

Enjoy!

 

-- Jim

 

P.S. - Apologies if this bothers anyone, but I plan to cross-post this to the Apple forum, since it appears to get a somewhat different set of users.

[waltr]

hi jim,

 

glad things worked out for you. i still stick by my original post. i think if you followed that methodology, you would not see these problems.

 

cheers.

 

ps--say hi to 'Dr Smoke'. haven't seen him around here in a while!

[CallMeDave]

Quote:

---

1. Why didn't those files get restored the first time 'round?

 

---

 

The problem here is that we don't know, step-by-step, what you did for either the Backup or for the Restore.

 

For example, we know the Backup Set contained the file you wanted, but we don't know if that file was in the Snapshot used for Restore.

 

Since you did a Live Restore, we don't know anything about the system you installed vs. the system on the Backup Set.

 

As I noted above, I'm not a huge fan of Live Restore. If your Backup Set contains the entire boot volume as a Source, booting from some other drive and restoring the Snapshot back onto a non-active volume will assure that everything in that Snapshot is written to the drive, with the same permission matrix as it originally had.

[jwarthman]

While I've made progress, I still have not gotten a successful restore.

 

I think we've had several threads intermingled here, resulting in some confusion. Let me add some detail that will help you understand what I've done (and am doing).

 

* Powermac G5 with OSX 10.4.7 (not 10.4.6 as posted earlier).

* Retrospect 6.1.126 / RDU 6.1.5.102

* Nightly backup to a backup set (56 sessions) on external Firewire drive

 

To restore my corrupt boot drive, I followed a procedure that used to be recommended by Dantz, but seems to no longer be recommended. That is, I boot from a separate drive, reformat the corrupt hard drive, reinstall the OS and upgrade to the version that was last backed-up with Retrospect. After several restarts (some of which involve booting to the volume with the newly-installed OS) I restart once again on the separate drive and launch Retrospect to do a restore.

 

As far as I can tell, I am NOT doing a live restore.

 

Here's where the confusion (and problems) begin.

 

Retrospect offers several choices for how to restore the entire hard drive, and the documentation is unclear about which to choose. It seems likely that several of these choices do the same thing:

 

Restore >

Restore Entire Disk > Restore Entire Disk

Restore Entire Disk > Replace Corresponding Files

Restore Entire Disk > Retrieve Files and Folders

 

Restore Files from a Backup > Restore Entire Disk

Restore Files from a Backup > Replace Corresponding Files

Restore Files from a Backup > Retrieve Files and Folders

et al.

 

When I use Restore > Restore Entire Disk > Restore Entire Disk, some files are NOT restored! For instance:

 

com.apple.dock.plist

loginwindow.plist

 

These were obvious omissions because they cause my dock to revert to default, and no applications launch at startup. I suppose many other files are not being restored.

 

Okay, I was able to confirm that these two .plist files ARE on the backup set. I used Restore > Search for Files and Folders, and easily located the files. Not only that, I was able to restore these files the same way. But I didn't keep that restore because I'm still searching for a method to restore everything, so I don't need to wonder what other files might be missing.

 

The thing is, when I view the "files chosen" for restore, none of the other restore methods listed above contain these .plist files! Why would these files show up with Search for Files and Folders, but not, for instance, with Restore Entire Disk?

 

Long story short, I have not restored my drive as yet, since I cannot know what files will be missing.

 

On an earlier attempt, I simply reformatted the corrupt boot drive and, while booted on the separate drive, used Retrospect to restore the entire disk. The results were the same - some files (notably com.apple.dock.plist) were not restored. I'm willing to try this method again and keep more detailed notes.

 

Regarding Snapshots... I have two snapshots on the Backup Set, and have been using the more recent. It's not clear to me if all these Restore methods treat snapshots the same.

 

In any case, if anyone can shed light on why these .plist files only SOMETIMES show up in my list of files to restore, I'd love to hear about it!

 

Best Regards,

 

-- Jim

[jwarthman]

After re-reading my post, I see that I can simplify my question.

 

Does the "Files Chosen" list show all files available to backup, with check marks to indicate the ones that were selected?

 

If that's the case, then why would some files appear in the list when doing "Search for Files and Folders" but not when doing "Restore Entire Disk"?

 

Thanks!

 

-- Jim

[CallMeDave]

Quote:

---

Why would these files show up with Search for Files and Folders, but not, for instance, with Restore Entire Disk?

 

---

 

One reason would be if the file is on the Backup Set somewhere, but not part of the Snapshot being used for the Restore.

 

Consider this scenario:

 

1- Hard drive backed up, all files are written to the Backup Set

2- User deletes a file

3- Normal backup (changed and new files copied to Backup Set)

4- Restore Entire Disk using Snapshot created after #3

 

Normal behavior would have the file deleted in #2 _not_ be restored to the drive, since it was _not_ present when the Snapshot was saved. But the file is on the Backup Set (since files are never deleted), and can be found by searching.

 

If you preflight a Restore Entire Disk with the Destination as an empty Volume, all the files in the resulting Browser list are all the files in the Snapshot. Any files missing from this list are missing from the Snapshot (not necessarily from the Backup Set). This would point to something involving how you did the Backup, not anything to do with how you're doing the Restore

[rhwalker]

Quote:

---

One reason would be if the file is on the Backup Set somewhere, but not part of the Snapshot being used for the Restore.

 

---

Dave is dead on right here. A common thing that people overlook is that, even if the folder with all of your catalogs in it is backed up as a part of your disk's backup, the catalog that is updated at the end of your backup is a generation newer than the version on your backup. Unless you have a final step in your backup to save away your final-updated catalog from the Retrospect backup, the first step in a bare metal restore should be to rebuild the catalog for the backup that you are going to restore so that it includes the files in your final backup to that storage set.

 

I also think that Dave is correct that a live restore is not as good as a restore to a quiescent disk. My comments above were simply a suggestion as to how a live restore should be done, if that's what you have to do.

 

Just a couple of suggestions.

 

russ

[jwarthman]

Dave & Russ,

That's very good feedback, thank you!

 

Fortunately, my backup set & catalog are intact on an external Firewire drive, so a catalog rebuild shouldn't be needed.

 

The comment about preflighting the Restore Entire Disk is also right-on. I've discovered that I can do this rather than wast time doing a restore, only to discover some of the expected files are missing.

 

Tonight when I get home I'll look more closely at snapshots. The difference between a snapshot and a session isn't clear. This backup set has 56 sessions and two snapshots. Honestly, I'm not sure what I did that "caused" the snapshots! But I now understand from your comments that the most recent snapshot probably omits some key files, for some reason. So I need some way of identifying all files on the backup set that are NOT part of that snapshot. Hopefully it's a small number, and won't include all the old versions of all the files in the backup set. :-)

 

Thanks!

 

-- Jim

[rhwalker]

Quote:

---

The difference between a snapshot and a session isn't clear. This backup set has 56 sessions and two snapshots. Honestly, I'm not sure what I did that "caused" the snapshots! But I now understand from your comments that the most recent snapshot probably omits some key files, for some reason.

 

---

 

I'm sure that some of the wiser and more accurate Retrospect people (users, support people) may wince when I say this, but here's my model of reality:

 

The "snapshot" is the state of the volume when backed up - list of files, if you will, location in the backup set, metadata, etc. The "session" is the list of files actually backed up (i.e., changed files, files that you specified to be backed up even if not changed, etc.). The snapshot might indicate that some files from the very first backup in the set are still present, and might also reference other changes located in various sessions (backups).

 

As to what "caused" the snapshots, that's how Retrospect works. That's its magic, so that you can pick a point in time in the past for restoration. That's why a backup is different from a clone (duplicate), because the various snapshots provide the historical pictures (snapshots) of the state of the drive. Perhaps you will better see the "big picture" if you launch Retrospect and go to "Configure > Backup Sets", select a backup set, click "Configure ..." to see the most recent snapshots, then click "Add", which will let you add older snapshots to the view.

 

Compare this to "Reports > Contents", select a backup set, select a session, click "Browse" to see what was backed up in that backup "session".

 

See the Retrospect User's Guide, Chapter 2 ("Fundamentals"), for a better discussion.

 

Russ

[twickland]

Quote:

---

The difference between a snapshot and a session isn't clear.

 

---

If you're doing a Normal incremental backup, each backup "session" includes only those files that are new or changed since the previous backup. The Snapshot, on the other hand, is a listing of all the files that were on the volume at the starting time of the most recent backup, and will include files that were backed up during various earlier backup sessions.

 

Quote:

---

This backup set has 56 sessions and two snapshots. Honestly, I'm not sure what I did that "caused" the snapshots!

 

---

Two snapshots mean that you have backed up two different volumes to this particular backup set. The number of times you've backed up volume 1 plus the number of times you backed up volume 2 since you first began backing up to this backup set totals 56.

 

Retrospect creates and saves snapshots by default unless you turn this feature off in the preferences. Snapshots are the key feature of Retrospect that enables it to perform incremental backups and still restore the volume to its state as of the most recent backup.

 

Quote:

---

But I now understand from your comments that the most recent snapshot probably omits some key files, for some reason.

 

---

I'm actually curious what volumes your two snapshots are for. Is it possible you selected the wrong one?

[CallMeDave]

Quote:

---

To restore my corrupt boot drive, I followed a procedure that used to be recommended by Dantz, but seems to no longer be recommended. That is, I boot from a separate drive, reformat the corrupt hard drive, reinstall the OS and upgrade to the version that was last backed-up with Retrospect. After several restarts (some of which involve booting to the volume with the newly-installed OS) I restart once again on the separate drive and launch Retrospect to do a restore.

 

---

 

This has never been, no my knowledge, the recommend procedure for a full disk Restore under OS X.

 

Dave