Restore error -1012 (feature unsupported)

[Bill Mullen]

I have just had my first major loss of data: 36 gigs of iPhoto files.

 

After running a restore I am left with 167 errors.

 

The restore occurred in two segments the first restore locked up after 9.6 gig.I had to force quit and on restart the log looked like this:

 

TFile::Open: UCreateFile failed, /Volumes/Retrospect/Retrospect/KaysiMacDATA_Disc/1-KaysiMacDATA_Disc/AA000053.rdb, oserr 6, error -1102

TFile::Open: UCreateFile failed, /Volumes/Retrospect/Retrospect/KaysiMacDATA_Disc/1-KaysiMacDATA_Disc/rdb_del.log, oserr 6, error -1102

 

On the second restore, since I had already restored a substantial number of files I selected the do not over write existing files option. After the restore was complete I had 160 + errors of the following type:

 

*File "Kays iMacData/Pictures/Aggie House/849484-R1-024-10A_020.jpg": can't duplicate to "Kays iMacData/Pictures/iPhoto Library/Originals/2008/Roll 1348/849484-R1-024-10A_020.jpg", error -1012 ( feature unsupported)

>

*File "Kays iMacData/Pictures/Aggie House/849484-R1-024-10A_020.jpg": can't duplicate to "Kays iMacData/Pictures/Stephanie Wed/Valerie Pics Wed/849484-R1-024-10A_020.jpg", error -1012 ( feature unsupported)

 

Can anyone tell me what this error is and how I can recover the error files. I get no errors when backing up.

 

Thanks,

Bill

 

Software update says I am running the latest 8.1 on my 2.4 GHz Intel Core 2 duo.

OSX 10.6.2

[CallMeDave]

[color:gray]File[/color]

"Kays iMacData/Pictures/Aggie House/849484-R1-024-10A_020.jpg"

[color:gray]can't duplicate to[/color]

"Kays iMacData/Pictures/Stephanie Wed/Valerie Pics Wed/849484-R1-024-10A_020.jpg"

[color:gray]error -1012 ( feature unsupported[/color])

 

Ouch. Looks as if Retrospect isn't matching things correctly.

 

I had to force quit and on restart

Force quit what? Restart what?

Is the Engine on the same machine as the Console?

What Type of Media Set is this?

 

Can anyone tell me ... how I can recover the error files

I'd run the entire Restore again, to an empty Volume or Favorite Folder. Why depend on a Restore that was interrupted before completion.

[Bill Mullen]

Dave,

 

Thanks for the reply,

 

I had to force quit Retrospect. It seemed as if the engine and the console were not communicating. It had been at the same place for a couple hours and telling it to stop did nothing. Quitting retrospect did nothing.

 

Yes the engine and console are on the same machine, but I am restoring to another machine.

 

The media is rbc disks on an external hard drive.

 

After finishing the second run, with 160 errors, my third run (which I started only in the hopes of cleaning up the errors) yielded an additional 80 errors. To my surprise even though the second run indicated that the process was complete, when I started the third run it said there was about 10 gigs to restore, which was about the size of the first failed run (maybe coincidence).

 

I will take your advice and restore to a folder I create on my attached hard drive. Since my first restore took about 18 hours, I'm sure it will go quicker to my external. The I'll take the drive to the other machine and move the contents onto it. This should work since all the files are jpeg & tiff and the iphoto library ???

Bill

[Bill Mullen]

Dave,

 

Thank you! 20 min for the whole restore with no errors.

 

I ran the restore on an external HD on the server with Retrospect. It reported no errors.

 

I am confused as to why I encountered the errors when using the network to the external HD on the client machine.

 

Not sure what I will do if I have to restore the client machine.

 

Unless you have a suggestion as to how to eliminate the errors on the client machine, I have one last question.

 

I was only restoring one folder on the client which contained only jpeg and tiff files and the iPhoto library.

 

Those, successfully restored, files are now on the servers external HD, which I have moved to the client machine.

 

I have successfully run iPhoto, on the client, using the library on the moved server HD.

 

Now, rather than do an 18hour restore, I would like to drag and drop these files from my servers external HD onto the clients external drive.

 

Will this work or will I encounter issues related to iPhoto?

 

Thanks,

Bill

 

BTW; On the thrice restored folder (on the client machine, done over the network), many of the subfolders had been moved up a level, and the drive reports having nearly twice the stored gigs as the source. Not a question just an observation.

[rhwalker]

Ah, the fact that you are restoring to a client machine seems to have been omitted in the original post.

 

(1) what version of Retrospect client on the client machine?

 

(2) what version of Mac OS on the client machine?

 

(3) what flavor of Mac OS (server, non-server) on the client machine?

 

(4) How were you restoring onto the client machine? Using Retrospect client? Or by mounting the client volume on the Retrospect machine?

 

russ

[Bill Mullen]

Hi Russ,

 

Thank you for the interest. I'll try to answer your questions.

 

01-25-10 04:19 PM - Post#134288

 

In response to ShamroxBill

 

Ah, the fact that you are restoring to a client machine seems to have been omitted in the original post.

 

(1) what version of Retrospect client on the client machine?

 

Client is 6.3.023

 

(2) what version of Mac OS on the client machine?

 

OS is 10.5.8

 

(3) what flavor of Mac OS (server, non-server) on the client machine?

 

Not sure how to answer this one, it is my wifes' iMac. Just a plain vanilla as far as I know.

 

(4) How were you restoring onto the client machine? Using Retrospect client? Or by mounting the client volume on the Retrospect machine?

 

I was restoring using the client.

 

I have no idea how to mount and restore. I am able to see my wifes computer using file sharing. Is there any advantage to mounting and restoring?

 

Thanks,

Bill

 

russ

[rhwalker]

Ok. From your responses, it appears that you are restoring through Retrospect client 6.3.023 on Mac OS 10.5.8 non-server (you would know if you had Mac OS Server on the client machine).

 

Are you aware that's not the most recent client? The most recent client, I believe, is 6.3.028:

Retrospect 8 updates

 

However, note that there are reports on the retro-talk email list that the 6.3.027 client is preferred over the 6.3.028 client because of some issues being reported with the 6.3.027 client. Search the archives:

Search retro-talk

 

Of course, there are no release notes for any of the Retrospect 8 clients, so no one has a clue what each version solves (or doesn't solve), or why it was released. Documentation seems to be lacking at EMC. Heck, Retrospect 8 has been out for over a year and there isn't any manual. Sigh.

 

You might try to repeat the results with client 6.3.027 or 6.3.028.

 

Russ

[Bill Mullen]

Thank you for the feedback, I'll try 6.3.027.

 

Bill

[Bill Mullen]

Russ,

 

I appreciate your help.

 

Using the client updater and the rcu file for 6.3.028 I updated the iMac.

 

At the time I was not aware that the source window of the console displays (what it thinks is) the revision of the client.

 

When you asked what revision of the client I was using I went to the client computer and did a get info on the client.

 

Since doing the update, the client get info on the computer remains at 6.3.023 while the window on the console indicates 6.3.028.

 

I am confused as to what flavor of the client I am using, or was using for that matter.

 

Do you have any idea how to tell which revision I am actually running, who do I trust (the client computers finder or the Retro console)?

 

I probably had been running the 6.3.027 as that is what came with my Retro 8.1 and on receipt of 8.1 I went to the client computer (which I had been using Retro 6.1 on for years) and did a manual install of the client without un-installing 6.3.023. The Icon was changed to the new one, but the revision; I guess not.

 

Any ideas?

[CallMeDave]

I went to the client computer and did a get info on the client.

 

Launch Retrospect Client.app and make sure it's Status is "Ready." It will display the version number in the upper right of the application's window.

 

 

Dave

[rhwalker]

It is also possible that you have two Retrospect clients installed on the client machine. The flavors of the Retrospect clients keep changing, and different installers are used. You may need to run the uninstaller for 6.3.023 to uninstall that one. There is no official uninstaller for the 6.3.027 or 6.3.028 client, but there seems to be an "unofficial" one posted by Robin Mayoff (head of EMC Retrospect tech support) in the Retrospect Windows forum (where else?):

Unofficial uninstaller for Mac Client posted in Windows forum

 

Because there is no documentation or read me for the clients, it's a bit of an experiment for users to come up with the magic combination that works. EMC product management seems in disarray.

 

Russ

[Bill Mullen]

Russ,

 

Thank you for the help.

 

I have, what I believe is, a properly installed client. A backup ran ok after removing the old client, restarting the Retrospect engine, adding the new client by IP # and running the backup from the script, with the new source added.

 

The next time I try to backup, or when the script does, it tells me the client is not available.

I have tried this process from another thread:

Problem is with the 8.1 engine

[color:purple]Remove the clients, stop engine, start engine, then add them again.[/color]

Sometimes the client is visible and sometimes it is not and I can only add it by IP#. Regardless of how it is added the client is no longer available a couple days later and the cliet IP is the same.

Should I look for another thread to post a question on this problem?

[rhwalker]

Sometimes the client is visible and sometimes it is not and I can only add it by IP#. Regardless of how it is added the client is no longer available a couple days later and the cliet IP is the same.

Client visibility happens when Retrospect is able to chat with the client. During discovery, it happens by multicast/broadcast. After the client is added, I believe that the chatting is still over port 497 as in earlier versions of Retrospect.

 

What does the Client show (on the client machine) as its status when this happens? Open the client, report what it says.

 

Are there any routers/hardware firewalls between the Retrospect engine and the clients that disappear?

 

Are there any software firewalls in play on the Retrospect engine or client?

 

Do all clients disappear at the same time, or do some clients disappear and others don't?

 

Are there any clients that never disappear?

 

Do clients have their energy settings set to sleep after some time?

 

If you wake the clients up with the WakeOnLan utility, do they now reappear?

 

The suspicion is that something happens to the clients after they go to sleep and reawake. Perhaps Retrospect client isn't doing something right when things wake up. It would be an interesting experiment to set a couple of clients to never go to sleep, see if the results change.

 

Should I look for another thread to post a question on this problem?

No, this thread seems fine because it hasn't been hijacked (yet).

 

Russ

[Bill Mullen]

Russ,

Before you answered I had gone thru the remove client, stop retrospect engine, start retropect engine, and add client.

The client was added by broadcast. I ran the backup script and it appeared to perform OK.

 

Then, since broadcasting seemed to be working I successfully added my windows 7 laptop to the client list and since the backup on that script is proactive it ran right away. It crashed once with a communication error, then locked up while building a data point (I forget the terminology) and then finally it ran a successful backup with no errors. I discovered after the second error that the laptop had decided on it's own, to restart during the backup.

 

So where I am now is everything is talking, I think. I don't expect to have problems until the next scheduled backup of the iMac which is 2:30am on 2/4/2010.

 

So I'll hold your list of questions until the phenomena surfaces again.

 

Thanks,

Bill

[Bill Mullen]

Russ,

 

The last client backup failed as in (from log):

 

Can't access volume Kays iMacData on Freida Mullen’s iComputer, error -530 ( backup client not found)

 

The Client was setup by broadcast (not IP) but co-incidentally the IP address for the client has not changed since it was setup.

Retrospect tells me that the client is not visible on the network when I try to "Refresh" the client.

 

Here is a shot at answering your questions:

 

[color:purple]What does the Client show (on the client machine) as its status when this happens? Open the client, report what it says.[/color]

 

Client is "on" and "Ready"

 

[color:purple]Are there any routers/hardware firewalls between the Retrospect engine and the clients that disappear?[/color]

 

There is a Linksys 4 port router, but I believe that it's firewall only looks at incoming traffic from the modem.

 

[color:purple]Are there any software firewalls in play on the Retrospect engine or client?[/color]

 

Yes, there are Firewalls on the Client (the Mac firewall is on, with Retrospect selected to allow incoming connections), the server has Netbarrier(with all my local IPs in the trusted group).

[color:purple]

Do all clients disappear at the same time, or do some clients disappear and others don't?[/color]

 

Yes, two clients (I only have two) are gone. Both still have the same IPs as when setup by broadcast.

[color:purple]

Are there any clients that never disappear?[/color]

 

No, other that the host machine backing itself up, the host backup has never failed.

 

[color:purple]Do clients have their energy settings set to sleep after some time?[/color]

 

Yes.

 

The Mac client has a script which wakens the machine 5 minutes before backup. The script is working, as I run Super Duper on alternate days on the client machine. Super Duper Requires the machine to be awake. I'm not PC literate so I usually run the backup when the laptop is on.

 

[color:purple]If you wake the clients up with the WakeOnLan utility, do they now reappear?[/color]

 

Not familiar with a utility. The client is set to wake for network access.

 

[color:purple]The suspicion is that something happens to the clients after they go to sleep and reawake. Perhaps Retrospect client isn't doing something right when things wake up. It would be an interesting experiment to set a couple of clients to never go to sleep, see if the results change.[/color]

 

I will set the client up to never go to sleep and see if that makes a difference.

 

Bill

[rhwalker]

Bill, see my link upthread for the WakeOnLan freeware utility.

 

As for the other stuff, three comments:

 

(1) if you set the clients up from broadcast rather than by IP, it doesn't matter if their IP hasn't changed. Retrospect then tries to find them by name. If broadcast/multicast isn't working, then it won't find them.

 

The suspicion has always been that some Macs on some versions of Mac OS don't wake up right (well, more correctly, Retrospect doesn't correctly reinitialize the connection when the Macs wake up). Your test about not sleeping will answer this question for your setup.

 

(2) it would also be interesting, if your IP addresses don't change, to try the experiment with the Macs set up with static IP addresses, so that the Retrospect discovery is not in play.

 

(3) There has been discussion about recent version of Mac OS having firewalls that don't play nice with Retrospect (that's not saying whose fault it is). It would be an interesting experiment to try with firewalls and Netbarrier off.

 

To my mind, Retrospect has always had problems in these areas and should be more robust. I guess that I just programmed differently in my youth than Retrospect's programmers do now. Regardless of where the problem is, it should "just work", and it used to before recent years with Retrospect. I'm tired of having to babysit this problematic child.

 

Russ

[Bill Mullen]

Russ,

 

An update:

 

[color:purple]Bill, see my link upthread for the WakeOnLan freeware utility.[/color]

 

Thank you I have it now. I'm not sure what to try. I have the client programmed to wake 5 min before Retrospect runs. Are you thinking that waking from the server would perform differently ?

 

 

[color:purple]As for the other stuff, three comments:

 

(1) if you set the clients up from broadcast rather than by IP, it doesn't matter if their IP hasn't changed. Retrospect then tries to find them by name. If broadcast/multicast isn't working, then it won't find them.[/color]

 

Yes.

[color:purple]

The suspicion has always been that some Macs on some versions of Mac OS don't wake up right (well, more correctly, Retrospect doesn't correctly reinitialize the connection when the Macs wake up). Your test about not sleeping will answer this question for your setup.[/color]

 

The backup has now run twice successfully with the client set to stay awake. Thank You!

 

Also, an observation, the second client (a windows 7 laptop) is visible after shutdown. And the pro-active backup runs OK.

 

This probably narrows it down to a client problem although the process that I used to get the backup client visible again was:

1 Remove the client from the retrospect control panel, 2 Stop the Retrospect engine, 3 Start the Retrospect Engine, 4 Add the client by Broadcast. 5 Repair the source in the script.

This does not involve any action on the client machine.

 

I will try running the Wake on Lan, if you think it might be productive.

 

[color:purple](2) it would also be interesting, if your IP addresses don't change, to try the experiment with the Macs set up with static IP addresses, so that the Retrospect discovery is not in play.[/color]

 

As an amateur I spent over 3 hours trying to find directions for setting my router and computers up for fixed IPs, unsuccessfully. I wouldn't know where to begin with this one, as my ISP uses dynamic assignment.

 

[color:purple](3) There has been discussion about recent version of Mac OS having firewalls that don't play nice with Retrospect (that's not saying whose fault it is). It would be an interesting experiment to try with firewalls and Netbarrier off.[/color]

 

This is one I can try.

 

[color:purple]To my mind, Retrospect has always had problems in these areas and should be more robust. I guess that I just programmed differently in my youth than Retrospect's programmers do now. Regardless of where the problem is, it should "just work", and it used to before recent years with Retrospect. I'm tired of having to babysit this problematic child.[/color]

 

I can relate, I am not a programmer, nor a computer master, a retired physicist yes. I used Retrospect 6.1 for many years with very few problems and I thought that 8.1 would continue in that tradition. Having moved from enjoying the challenge of building computers (I built an Apple II when they first became available) to wanting only to use computers as a tool. I am distressed at the lack of quality associated with what used to be the premier backup software for business and home. Retrospect is my third line of defense in the world of protecting my data and my ability to get back up and running quickly in the event of a crash. Today I use Super Duper to clone Periodically and I use Time Machine to do hourly backups. I have on four occasions, one recently and three pre-Time machine, lost something major and due to operator error a clone of the defective drive was run before the problem was recognized. In those cases Retrospect came to the rescue.

 

I appreciate your babysitting effort as I think you have given me enough information to run for a while.

 

Right now I have three things to try;

 

A. Use Wake on Lan & see if a difference is observed.

 

B. Turn off all firewalls and check again.

 

C. I'm going to see if I can script a process to:

1 Remove the client from the retrospect control panel, 2 Stop the Retrospect engine, 3 Start the Retrospect Engine, 4 Add the client by Broadcast. 5 Repair the client script.

 

This last try is a real kludge but unless you already know it won't work I'll give it a try.

 

Bill

[rhwalker]

[color:purple]Bill, see my link upthread for the WakeOnLan freeware utility.[/color]

 

Thank you I have it now. I'm not sure what to try. I have the client programmed to wake 5 min before Retrospect runs. Are you thinking that waking from the server would perform differently ?

No, I'm trying to find out why they don't wake. If they can be awoken by an independent sender (the WakeOnLan utility) from the same server, then you know it's not a network infrastructure, firewall, or WOL hardware issue on the client, but instead is yet another Retrospect bug.

 

If the WakeOnLan program can't awaken the client, then you need to investigate your network, firewalls, etc.

 

Even so, there is a suspicion that Retrospect on the client doesn't correctly re-initialize the network connection on the client (the Port 497 stuff) when it wakes up. This would provide an independent test of that possibility.

 

 

The backup has now run twice successfully with the client set to stay awake. Thank You!

 

Also, an observation, the second client (a windows 7 laptop) is visible after shutdown. And the pro-active backup runs OK.

Ok, this still doesn't answer where the problem lies.

 

(a) is it the failure of Retrospect server to wake the client up, perhaps because of something in your network infrastructure? See comments above, WakeOnLan utility test will answer this.

 

( or, is it the failure of Retrospect client to properly re-initialize the network connections after waking up? Again, the WakeOnLan utility test will answer this.

 

I will try running the Wake on Lan, if you think it might be productive.

Yes, I do. Seems that we have to do EMC's Software QC/QA for them, because there doesn't seem to be any testing before release. This particular bug is one that has existed for a long time.

 

As an amateur I spent over 3 hours trying to find directions for setting my router and computers up for fixed IPs, unsuccessfully. I wouldn't know where to begin with this one, as my ISP uses dynamic assignment.

Ok. This has nothing to do with how your ISP provides a WAN IP address to your router. It only has to do with how your computers on your LAN are set up behind your router. I assume that your router is doing NAT and that you have your router set up to assign IP addresses to your LAN computers by DHCP.

 

Understand that there are two parts for this setup.

 

First, and most important, you don't want to take the chance that your router's DHCP server (assuming you are doing NAT and are assigning IP addresses by DHCP from your router) will assign a DHCP lease at the same IP as you have a client set up for a Static IP. That's to prevent two computers from getting the same IP, which would cause grave disorder. So, you need to have the DHCP scope (range of IP addresses) non-overlapping with the static IP addresses that you give your client computers, but still in the same subnet.

 

Example: If you have your LAN subnet as 192.168.0.x (192.168.0.0/24), then you might have your Router's gateway LAN address at 192.168.0.1, your DHCP scope as 192.168.0.2 - 192.168.0.50, and then assign static IP addresses from 192.16.0.51 upward so that there is no overlap.

 

Second, to set a static IP on a Mac, go to the System Preferences, Network pane, make a new location (default is "Automatic", make a new one called Retrospect (or whatever)), click "Configure", TCP/IP tab, Configure IPv4 "Manually", enter all setup items that would normally be provided by the DHCP lease - IP address, subnet mask, Router gateway address of your router, DNS servers, etc. That should do it.

 

You seem to be going in the right direction. Your item C scripting probably won't work because Retrospect 8 is not (yet?) scriptable. That's a serious problem when trying to use Retrospect in a server environment, where services (mail, etc.) have to be stopped and checkpointed prior to backup by Retrospect. I will be amazed if you are able to get your item C to work.

 

Good luck.

 

Russ

[Bill Mullen]

With firewall off or on WakeOnLan wakes the client and the backup script executes.

Following the WakeOnLan instructions to compile an appleScript; If I use the computer name the script fails to wake the computer, if I use the IP# it succeeds.

Example:

 

tell application "WakeOnLan"

wakeup "192.168.1.103"

end tell

 

Ignoring that puzzle I scheduled WakeOnLan to wake the client and retrospect to run for this week. I should know how this works in a hands off environment in a few days.

 

As you anticipated I was not able to script the shutting down of the retrospect engine.

 

Thanks for your help, I think I'm close.

[CallMeDave]

If I use the computer name the script fails to wake the computer, if I use the IP# it succeeds

 

What does "the computer name" mean in this context?

 

Is it a fully qualified domain name? Does it use .local?

[Bill Mullen]

In WakeOnLan there is a computer name in column 1. I have no idea where it comes from as it bares no resemblance to the actual computer name.

But the script directs WakOnLan to wake that computer name (the one it created).

Note the script that uses the IP # also works through WakeOnlan.

I should know by tomorrow if my overall system is working, with WakeOnLan being an integral part.

Maybe Iomega should consider buying this app to include in its' software.

Actually if my system is working now I'm going back to golf to expend my creative energies.

Thanks again,

Bill

 

[CallMeDave]

In WakeOnLan there is a computer name in column 1. I have no idea where it comes from as [color:purple]it bares no resemblance to the actual computer name[/color].

 

That's odd; when I run WOL the first column displays the Bonjour computer name, exactly as shown in the System Preference's Sharing pane of each Mac on my network.

 

If you visit the Sharing pane in System Preferences and click on the "Edit..." button you'll see the fully qualified hostname with the Bonjour specific "local" domain. You'll probably want to use this in your Apple Script.

 

 

Dave

[Bill Mullen]

Good info, thanks.

 

In WOL the name is: "John Smith's iComputer"

 

In Sharing panel it is identical.

 

In EDIT from sharing panel it is: "John-Smiths-iComputer".

 

In my script should I use "John-Smiths-iComputer"?

 

Should I add the .local which is greyed out in the edit field?

 

Bill

Edited February 11, 2010 by Guest

[Bill Mullen]

Just when you think you are close...O.M.G.

Everything ran perfect last night: WOL executed, Super Duper ran, Retrospect backed up the client but:

On starting the console this morning I am presented with an empty pallet. The first thing the console does is ask me for a product KEY, unless I would like to "Try It". Having entered a key I have a clean slate, no clients (or sources) no backup media, no scripts but I do have an operations log.

 

This happened a few days back and I used Super Duper to revert to the night before which worked but it cost me the backup history for the evening.

 

This morning I used time machine to restore the console program to no avail.

 

[color:red]Looking in the Hard drive library/preferences/retrospect I find these files:

 

LaunchRetroHlper

Operations Log

Retro.Config (6.0)

Retro.Express Config (6.0)

Retro.Icons (6.0)

retrorunfile

Retrospect.error.log.c2d0e05e

Retrospect.error.log.c33d88b7

Retrospect.error.log.c253bbd4

Retrospect.error.log.c36270f4

Retrospect.error.log.c362711b

Retrospect.error.log.c362833e

Retrospect.error.log.c362845e

[/color]

 

Seems like all the ones above, in red, are old files, probably associated with Retrospect 6.

 

Looking in the HD/librry/applications support/retrospect: I find:

 

Catalogs

Config80.bak

Config80.dat

operations_log.utx

retro.ini

RetrospectEngine.bundle

RtrExec.dir

 

I can restore any of these using Time Machine but I'm not sure which, if any, will get my console setup back.

 

Do you have any idea?

 

Also would you have any guesses as to why the Retro Console is cleared after a successful backup?

 

Bill

 

Edited February 11, 2010 by Guest

[Maser]

All the application configuration information is stored in "Config80.dat".

 

If it's been "zeroed out", you can restore an older version of this from backup.

 

 

The most common reason for it to zero out would be if the engine is repeatedly (and frequently) crashing (you can check your crash log folders to see if this is the case).

 

If this wasn't the case for you, I'm not sure why it otherwise would have reset to the default.