Restore problem - disk not bootable

[wsussman]

Howdy all,

 

I'm trying to use Retrospect for Mac to back up a computer to a NAS volume. The NAS would then rotate off-site. I'm testing the procedure and everything seems to work just fine until I try to restore from the NAS to a similar but not identical computer (another Mac that is similar to the backup machine-operating on the theory that the original computer is not available).

 

The restore seems to go without a hitch, but when I reboot from the restored volume I get a grey "do not enter" logo. If I hold down the option key, the Mac sees the restored volume as boot-able but if I select it I hang at the grey apple screen. OS is 10.4.11, version of Retrospect is 6.1.138 and I'm running out of options.

 

Thanks for any assistance,

Webb Sussman

[Mayoff]

What model of Macintosh was used as the backup source?

 

What model of Mac was used for the destination?

 

What OS version was backed up?

 

What OS version was installed on the destination prior to the restore?

[wsussman]

Both Macs are Dual 867 G4s running OS X 10.4.11

 

The NAS they are backing up to is a LaCie Big Disk 1 TB Ethernet drive

Edited March 6, 2008 by Guest

[CallMeDave]

The NAS drive is a red herring.

 

You have to provide to use the exact steps you took to perform the Backup, and then you have to detail the exact steps that you are taking to perform the Restore.

 

List every step, every mouse and button click, describe every window, every choice you make.

 

We're out here in the wilderness without cold, hard facts.

 

 

Dave

[Mayoff]

I suspect the failure is caused by something in the restore steps. Are you doing a Restore Entire Disk operation?

 

What OS version was installed on the destination prior to the restore?

 

[wsussman]

Sorry folks, additional detail follows:

==========

We're using Retrospect Workgroup, version 6.1.138 with matching clients for Macintosh. The company is a Mac shop so no Windows environments.

The test source system is a "Quicksilver" Mac G4 with 1.5 GB RAM running system 10.4.11

The Retrospect Server is a "Mirror Face" Mac G4 with 2 GB RAM running 10.4.11

The test restore system is a "Mirror Face" Mac G4 with 2 GB RAM running 10.4.11

All computers have energy saving and screen saving turned off and are set not to go to sleep.

The NAS is a LaCie 1 TB "Big Disk" Ethernet hard drive

The test network is running on a Linksys gigabit 5 port switch using cat 5E cable. Cables are all tested and "known good". Switch is tested and "known good".

 

In our test we are backing up from the test source to the NAS across the test network, and then restoring from the NAS to the test restore system across the same network.

 

When creating the backup we mount the test source on the Retrospect server desktop. The test source is the system volume so "ignore permissions" is not an option on the backup. The target restore volume is NOT the primary system partition on the restore Mac so "ignore permissions" _is_ turned on there.

 

For purposes of the test, we have the NAS mounted on the desktop of the Retrospect server as well. When this moves to production, we will modify the script so that the NAS does not have to be mounted.

 

BACKUP: Launch Retrospect Server

Click on the "automate" tab - schedule a backup - set time to be +10 minutes from "now"

Click on the "Scripts" button

Choose the NAS script and edit it

Source=Test Source

Destination=NAS

Selecting=All Files

Options=verification on

Don't back up FileVault

Schedule: Single Date

Start= +10 minutes from "now"

Action=Normal Backup

Quit Retrospect

Get Dialog Box="...is everything ready?"

Click "Yes" button and then quit

 

Total size of Test Backup=@12 GB

Backup kicks off as scheduled and appears to run successfully resulting in a 135.4 MB catalog file and a 12.27 GB backup set

 

RESTORE: Mount the NAS and the Test Restore volumes on the desktop of the Retrospect Server

 

Launch Retrospect

Click on the "Restore" button

Restore Source window opens

Click on "Restore Entire Disk", then click "OK" button

Destination window opens

Select Test Restore volume

Dialog opens:"Really restore to 'Test Restore' replacing entire contents?"

Click "Replace" button

Dialog "Restore from Backup" opens

Source=Test Backup set

Destination=Restore Test volume

Replace Entire Contents shows in red below this

Files Chosen=248,800 files (@12 GB)

Options=Normal

Click Restore button

Get dialog box asking "really restore entire contents?"

Click "OK" button

Restore starts

Get "Restore from Backup" window with progress bar.

Performance of source is @100 MB/minute.

 

At this point we see one of two types of failure. The most common failure is that the Restore will fail with an "Execution incomplete" error. From the test run above:

'Date', 'Time', Execution incomplete

Remaining: 153754 files, 7.7 GB

Completed: 95054 files, 3.2 GB

Performance: 89.1 MB/minute

Duration: 00:36:42 (00:00:02 idle/loading/preparing)

 

If we close the window and go to the log file the error there reads: "Can't write file 'x' (for example x=BJPrinterUtility), error -1 (unknown), path: "Macintosh HD/Library/Printers/Canon/BJPrinter/Frameworks/BJPrinterutility.framework/BJPrinterUtility".

Trouble writing files, error -1 (unknown)

 

The second type of failure we see is that Retrospect completes it's run apparently successfully. The Test Restore drive does not boot in either case however.

=============

Hopefully that is enough detail to get started with. Please let me know if I can provide any additional information. We would very much like to get this setup working ASAP.

 

Webb Sussman

[CallMeDave]

We appreciate all the detail.

 

Retrospect backups up Sources, which can be either partitions on a disk, or folders on a disk that have been defined as a Subvoume. So when you write:

The test source is the system volume

that would literally mean that your Source is /System/, which is unlikely the case. So confirm that your Source is / on the client machine?

 

Retrospect backs up to Destinations, which is the Backup Set that consists of the catalog and the media. So when you write:

we are backing up from the test source to the NAS across the test network

and

Destination=NAS

A better description would be that your Destination is a File Backup Set stored on the network attached storage share point.

 

Some other things are not described, such as exactly what hardware is being used as the Destination for the Restore operation. But, if the following is accurate, then it is the cause of your failure:

 

The target restore volume is NOT the primary system partition on the restore Mac so "ignore permissions" _is_ turned on there.

If "Ignore permissions" is enabled on the Destination volume for a Restore, then the Restore will not be bootable. That's why there's a big warning dialog displayed if you attempt to do it.

 

 

Dave

[wsussman]

Thank you - I'll change that setting and re-test

[wsussman]

You were/are correct:

The Source for the restore is /Snuffy1 (the NAS).

The Destination for the restore is / on the client machine.

The hardware description was included in the earlier detail post in this thread (multiple G4s and the NAS).

 

I have since changed the "ignore permissions" setting on the Destination volume and have a different result: the restore runs for approximately 823 MB and then quits with an "Trouble writing files error -1 (unknown)" error with approximately 11 GB left to restore. All three hard drives test out OK and I can "finder copy" information back and forth to all three volumes. It's only Retrospect that seems to have difficulty with the Destination.

 

Any other ideas? I could still use help here.

 

Webb

Edited March 10, 2008 by Guest

[CallMeDave]

Retrospect Restores from a Source, which is the Backup Set that consists of the catalog and the media. So when you write:

 

> The Source for the restore is /Snuffy1 (the NAS).

 

A better description would be that your Source is a File Backup Set stored on the network attached storage share point (Snuffy1). Is that true?

 

> The hardware description was included in the earlier detail post in this thread (multiple G4s and the NAS).

 

OK, so when you wrote: The target restore volume is NOT the primary system partition on the restore Mac

 

would it be fair to infer that the target restore volume IS a partition on the internal HD, or a secondary installed HD, of the G4 Mirror Door?

 

(in general, knowing what things are is preferable to hearing about what things are not)

 

All three hard drives test out OK

 

Now I'm confused again. What are the three hard drives? I thought that this was a File Backup Set stored on a NAS (hard drive 1) that was being used as the Source to Restore a hard drive (or partition of a hard drive) installed in a G4 Mirror Door (hard drive 2)? What other hard drive is being used?

 

...the restore runs for approximately 823 MB and then quits with an "Trouble writing files error -1 (unknown)" error

 

- Is the Destination a freshly erased volume?

 

While the fact that your File Backup Set is being stored on a NAS was inconsequential to your original problem, it would be reasonable to take that hardware out of the mix in order to test why your Restore is failing. So one test you could try would be to copy the 11 GB File Backup Set (both files; "Foo" and "Foo.cat") to the machine running Retrospect. Then attempt the Restore to the client machine using that Backup Set (first, forget "Foo" from the list of Backup Sets in Configure->Backup Sets. Then either use the "More" button there, or just double click on the newly copied ".cat" file to get Retrospect to know about the new location; Restore as usual).

[wsussman]

Sorry for the confusion Dave,

 

Retrospect Restores from a Source, which is the Backup Set that consists of the catalog and the media. So when you write:

 

> The Source for the restore is /Snuffy1 (the NAS).

 

A better description would be that your Source is a File Backup Set stored on the network attached storage share point (Snuffy1). Is that true?

 

Yes

 

> The hardware description was included in the earlier detail post in this thread (multiple G4s and the NAS).

 

OK, so when you wrote: The target restore volume is NOT the primary system partition on the restore Mac would it be fair to infer that the target restore volume IS a partition on the internal HD, or a secondary installed HD, of the G4 Mirror Door?

 

(in general, knowing what things are is preferable to hearing about what things are not)

 

Sorry about the confusion. The target restore volume is a partition on the internal HD of the G4 Mirror Door.

 

All three hard drives test out OK

 

Now I'm confused again. What are the three hard drives? I thought that this was a File Backup Set stored on a NAS (hard drive 1) that was being used as the Source to Restore a hard drive (or partition of a hard drive) installed in a G4 Mirror Door (hard drive 2)? What other hard drive is being used?

 

In addition to checking the NAS and the Destination drives, I also checked the original source drive to rule out a corrupted/potentially corrupted backup source.

 

...the restore runs for approximately 823 MB and then quits with an "Trouble writing files error -1 (unknown)" error

 

- Is the Destination a freshly erased volume?

 

Yes

 

While the fact that your File Backup Set is being stored on a NAS was inconsequential to your original problem, it would be reasonable to take that hardware out of the mix in order to test why your Restore is failing. So one test you could try would be to copy the 11 GB File Backup Set (both files; "Foo" and "Foo.cat") to the machine running Retrospect. Then attempt the Restore to the client machine using that Backup Set (first, forget "Foo" from the list of Backup Sets in Configure->Backup Sets. Then either use the "More" button there, or just double click on the newly copied ".cat" file to get Retrospect to know about the new location; Restore as usual).

 

I'll attempt that test shortly. Thank you for your patience.

 

Webb

[wsussman]

Dave,

 

I did as you suggested and moved the backup file and backup cat file to the Retrospect Server and then attempted a restore from there last night. I got an error message about 1/2 way through the restore. The error message was identical to the previous error message ("Trouble writing files error -1 (unknown)").

 

I'm out of ideas. Any suggestions?

[Mayoff]

Error -1 Unknown may be caused by a problem on the destination volume. What happens when you try to restore the same data to a different location

[wsussman]

I thought of the same thing. We get the same error restoring to an entirely different volume on an entirely different computer. I'll try pulling a machine out of storage and restoring to that. I'll report back on that shortly.

 

I've checked the drives on all of these systems with Diskwarrior which reports no errors. I've checked the network cables. The computers boot normally. I'm running out of ideas.

Edited March 11, 2008 by Guest

[CallMeDave]

So far, you've seen the error in two entirely different hardware configurations:

 

Source: File Backup Set on NAS

Destination: Client non-boot volume

 

Source: File Backup Set on local volume

Destination: Different client non-boot volume

 

So I'd suggest that the next test would be to take the client software out of the mix, and attempt a Restore such as:

 

Source: File Backup Set on local volume

Destination: Local attached volume

 

If _this_ fails as well, the only remaining thing that's consistent across all tests is the File Backup Set itself. Therein might lie the problem.

 

 

Dave

[rhwalker]

I'll offer my two cents for what it's worth even though, from the reports here, it appears that the problem is on the destination, not the source.

 

The file backup set is on a NAS and is somewhat large (11 GB). No information has been provided as to how the NAS share is presented to Retrospect's computer (that might be useful info). Perhaps it's an old version of AppleShare. Perhaps it's some other type of FS. My point is, maybe the problem occurs when Retrospect tries to do a seek() or some such on the file backup set to pull in the files of the snapshot. That's a different scenario than the sequential read() that occurs during the verify phase of the backup. I'm just wondering here because so much has been tried.

 

Because these are all G4 Macs running MacOS 10.4.11, no ACL issues would be involved (unless a Universal Binary version of 10.4.x from an Intel Mac was used to create those installs and ACLs were turned on from the command line, which seems unlikely). Also, no Rosetta issues could be involved because these are G4 machines, and the Retrospect client is pretty well shaken out on PPC.

 

One other thought - Because this is a NAS, perhaps something in the client is timing out because the NAS and the client are competing for the same ethernet channel. Seems very unlikely because the network infrastructure is GigE with only a single switch and no routers involved, but I toss it out. Would have to be something very odd, like an ARP storm or the like, but I can't imagine that on such a simple network setup.

 

Just a couple of thoughts...

 

I did as you suggested and moved the backup file and backup cat file to the Retrospect Server and then attempted a restore from there last night. I got an error message about 1/2 way through the restore.

 

Ok, ignore my comments about the NAS - I didn't see this little tidbit of information. Can't be the NAS because of this test (unless the backup set was already corrupted before being copied over to the server's local drive).

 

Russ

Edited March 11, 2008 by Guest
PEBKAC about NAS

[CallMeDave]

from the reports here, it appears that the problem is on the destination, not the source.

Depending on the results of the next round of tests, you might still be correct Russ. But not in the way you originally intended!

 

Since the backup was created when the File Backup Set was stored on the NAS, maybe the problem was with the Destination of the Backup, not the Source (of the Backup).

 

 

> Can't be the NAS because of this test (unless the backup set was already corrupted before being

> copied over to the server's local drive).

 

 

Bingo!

[wsussman]

OK folks - I'm dropping back to basics. This mornings test will consist of simply backing the Source up to a Destination which is a new backup set residing on a local volume on the Retrospect Server. This will be a completely new backup set with fresh data. The NAS is dropping out of the equation for right now. I'll then restore to a non-system volume on a third computer and see what we get.

Edited March 12, 2008 by Guest
Language suggestions provided by Dave

[CallMeDave]

This mornings test will consist of simply backing the Source up to a Destination which is a local volume on the Retrospect Server.

 

Arrrrrggggghhhh!

 

 

The Destination for a Backup is not a volume.

The Destination for a Backup is a Backup Set.

 

 

 

Dave

(I'd better have some Cheetos and a Snapple; then I'll feel better...)

Edited March 12, 2008 by Guest

[wsussman]

Sorry Dave, I'm new at this and still "learning the language". I'll make corrections in the original post.

[wsussman]

OK folks, sorry for the delay in reporting back, but the real world intervened.

 

Set things up so I had 3 computers. The "original" computer which contained the data we wanted to back up, the Retrospect Server, and the "target" computer which we wanted to restore to. All three computers were/are Mac G4 running OS 10.4.11 with at least 1.5 GB RAM (the "original" is a Quicksilver, the server and "target" are "Mirror Face"). Per Dave, we took the NAS hardware completely out of the equation for now (but everyone keep in the back of your minds that the ultimate goal here is to get the NAS to work with Retrospect).

 

I backed up the QuickSilver to a backup file stored on a secondary volume on the Retrospect server (it has 2 internal HD and I used the second one), erased it first so that the only files on it would be the Retrospect backup file and the Retrospect cat file and started a backup. The source of the backup was "/" on the QuickSilver and the destination was "/Volumes/73 GB Disk 2/Test-Direct" on the Retrospect Server.

 

This ran with 45 errors: all the errors were -5000 (server, no privileges) and all 45 files were "system" files (see attached log file).

 

We then ran Retrospect again to restore the files/folders to the "target" computer. The source of the restore was "/Volumes/73 GB Disk 2/Test-Direct" and the destination was "“Macintosh HD/*/*.*" (again, see log file attached). I attempted the restore 3 times and each time it hung on a different file in a different directory.

 

Any more suggestions folks?

[CallMeDave]

We're using Retrospect Workgroup, version 6.1.138 with matching clients for Macintosh

 

- Confirm that you are running Retrospect OS X Client software on both the "original" and "target" machines? And that Retrospect is communicating with each of these machines via the client software, and not through any sort of file sharing protocol?

 

Dave

 

---- edit----

 

 

Actually, reading the log more carefully, it looks as if it answers my question, as the Restore log gives no entries about connecting to a client.

 

Sigh.

 

My own fault, I suppose, for not challenging the omission of specific client version in the original post.

 

So, please describe exactly how Retrospect is communicating with the "original" machine, and exactly how Retrospect is communicating with the "target" machine.

[wsussman]

Dave,

 

You may have hit on part of the problem. I had dragged these computers out of storage and had neglected to update their client software. Because of my setup, Retrospect was actually using AFP to talk to the client computers.

 

They are now running the current version of the client software (6.1.130) and I am re-running the tests with this setup. This may not be the end of the thread, however, as I don't see how I'm going to load the client on the NAS.

 

Webb

[CallMeDave]

It's perfectly fine to store a File Backup Set on a remote AFP or CIFS volume.

 

It's also possible to backup data that resides on a remote AFP or CIFS volume, but permissions will not be maintained. So since the original post of this thread was about attempting an operation where maintaining correct ownership is critical, you can't restore to a remote volume and expect that volume to be bootable.

 

This all could have been sorted out the first day if you'd included a detailed description of exactly what you were doing.

 

Cheers,

 

Dave

[wsussman]

Just wanted to say "Thanks" to all who posted suggestions for me here, especially Dave. We finally got the backup working with the NAS. A combination of problematic NAS settings, my being new with Retrospect and it's settings and one bad network cable all contributed to this. The good news is that it is now functioning and functioning correctly.

 

Let's mark this one closed and thanks again all.

 

Edited March 21, 2008 by Guest