Restore error -1012 (feature unsupported)

[rhwalker]

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.

Big mistake. The request for a license indicates that Retrospect has barfed all over its config80.dat (preferences) file, as this buggy software is known to do, and that the config file is hopelessly corrupted. When you entered the product key, you caused Retrospect to wipe out its config80.bak (backup preferences), causing you to lose the chance to recover by renaming the .bak file to .dat.

 

Now you have an unconfigured Retrospect (no scripts, schedules, etc.).

 

You have three choices.

 

(1) If you saved away a good config file, quit the engine and the console, copy that good config file onto the bad one, delete the .bak file, restart engine and console, move forward.

 

(2) reconfigure from scratch - very painful

 

(3) bootstrap yourself up and restore an older good config file from your backup set (um, media set in newspeak). You have entered a license code, so you should be able to locate your media set, find the config file in there (wouldn't a working preview be nice?), restore to someplace on your desktop or otherwise, then follow the steps from (1), above.

 

Reliable software would be nice.

 

Good luck,

 

Russ

[Bill Mullen]

I took the easy way out and restored the clone I built immediately before Retrospect ran.

 

All looks OK, but the only indication that the client was successfully backed up is in the client software.

 

Assuming there is a next time I will stop the engine and console and use Time machine to restore the two config files.

 

Is there a way from within the Retrospect console to revert to the config.bak? Should I just go to the config files and delete the .dat and rename the .bak to .dat

 

Does the engine and the console have to be off to make the file changes?

 

Sorry for all the questions, I have a tee time tomorrow at 9am.

 

This program is redefining irritation.

[rhwalker]

Assuming there is a next time I will stop the engine and console and use Time machine to restore the two config files.

It's not a question of if, but when. The software is a bit unreliable right now.

 

Is there a way from within the Retrospect console to revert to the config.bak?

No. Sounds like a feature that would be useful.

 

Should I just go to the config files and delete the .dat and rename the .bak to .dat

Well, I think it would be better to copy the old ones away somewhere so that you could move them back if that's not the problem.

 

Does the engine and the console have to be off to make the file changes?

It's the "open file" problem. If a unix program has a file open, even if you delete the file or replace it, the program still has a handle on the inode, and the program might decide to overwrite the copy you just restored.

 

Sorry for all the questions, I have a tee time tomorrow at 9am.

Life sounds tough.

 

This program is redefining irritation.

Yep. It used to be reliable years ago. To me, a backup program ought to be the most reliable program you have. You are putting your trust in the program to preserve your data.

 

Russ

[Bill Mullen]

An update.

 

Have tried fixed IPs, finding by broadcast or manually setting (tried both ways).

 

Am using WOL, which works. IE: it wakes the client.

 

Have reinstalled the client and the engine.

 

Everything works, except Retrospect.

 

My guess is the client looses visibility on the network once the client computer has slept. Does not matter if I use WOL or go to the client physically and wake it up.

 

The log looks like this:

 

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

3/1/2010 3:22:30 PM: Execution incomplete

 

At this point I am at a loss for options other than to complain about iOmega selling me software that does not work.

 

I guess I'll just get used to: forgetting the client, stopping and starting the engine, re-finding the client and then backing up the client. It is hard for me to imagine how a person responsible for several computers could tolerate this liability.

[CallMeDave]

My guess is the client looses visibility on the network once the client computer has slept. Does not matter if I use WOL or go to the client physically and wake it up.

 

I guess I'll just get used to: forgetting the client, stopping and starting the engine, re-finding the client and then backing up the client.

 

Does it have to be so drastic (Removing the Client from the Sources list; "forget" is no longer a term in Retrospect 8)?

 

The thread has morphed from your original subject so I'm unsure if you've attempted more moderate ways to get the Retrospect Engine to see a Retrospect Client installed on a Macintosh that has awoken from sleep. Have you?

[Bill Mullen]

Dave,

 

My mistake, I am still in the Retrospect 6 language.

 

I have tried many ways to bring the client visibility back. Every suggestion from this thread has been tried. Not allowing the client nor the server to sleep may have worked (I don't remember for sure) but I find that solution unacceptable.

 

If you have a suggestion as to how I can restore the client visibility with less drastic actions I certainly would appreciate your input.

[CallMeDave]

Every suggestion from this thread has been tried

 

You've taken us on quite a journey in this thread. The Original Post was a report of error -1012 ( feature unsupported) on Restore.

 

Then there was some discussion about client versions and other observations.

 

Your 7th post in the thread was the first indication of a client communication error, and it was also the first time you thought you should [color:purple]"Remove the clients, stop engine, start engine, then add them again"[/color]

 

Your next post mentions the success when you [color:purple]"remove client, stop retrospect engine, start retropect engine, and add client"[/color]

 

The thread then morphs into one about WOL, with Russ repeatedly suggesting that the issue is with the client's behavior after sleep, with no indication that you were following his path of reasoning.

 

Then a post about using AppleScript to

[color:purple]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.[/color]

 

More talk of WOL workings, then a few posts about a munched preference file.

 

A later update informs us that you

[color:purple]"reinstalled the client and the engine,"[/color]

(presumably after first removing the client from the retrospect Console, etc) and finally the decision to simply [color:purple]"just get used to: forgetting the client, stopping and starting the engine, re-finding the client and then backing up the client."[/color]

 

Nowhere in the thread to I see any indication of you doing anything else to try and get the Client to be seen by the Engine.

 

If you have a suggestion as to how I can restore the client visibility with less drastic actions I certainly would appreciate your input.

 

I really don't have a suggestion as to how you _can_ restore the client visibility after sleep, but I would certainly be interested in knowing what happens when you simply restart the retroclient process on the invisible client machine.

[Bill Mullen]

Yes the thread was quit convoluted. The solution to the original problem was to bring an external hard drive to the server machine and restore to it, as restoring over the network was riddled with errors, then return the hard drive to the client. This is not a good solution, but since recovering from a disaster is something that occurs infrequently I can live with the solution.

 

I n answer to your question.

This morning the client was "Unavailable". I determine this by doing a refresh from the sources panel.

 

So I proceed to the client machine, Open the Retrospect client, Set the client to the "off" position. Close the client, Open the client and set the client to the "on" position.

 

Return to the server and do a refresh on the source, result is the same; "Source Unavailable.

 

Is that what you had in mind?

 

I should add that I have, since my last post been in touch with tech support who has helped me understand my problem and provided me with a temporary fix, which should carry me until the next release of the Retrospect engine.

[CallMeDave]

Is that what you had in mind?

 

Almost.

 

Simply clicking on the "Off" radio button does not kill the retroclient daemon; it leaves the process running but configured to be silent. [color:purple]"Turned off"[/color] is what Status field will say.

 

To actually restart the client process you need to hold the Command key as you click the "Off" radio button; the Status field needs to read [color:purple]"Not running"[/color] for the retroclient unix daemon to actually be dead. Then you can click the "On" radio button normally.

 

a temporary fix, which should carry me until the next release of the Retrospect engine.

 

Unless the issue is actually with the client, in which case a change in the Engine probably won't fix it.

 

Note that you can kill/start the retroclient process via the command line; a desktop visit isn't necessary.

Edited March 3, 2010 by Guest
added CLI option to kill/restart retroclient

[Bill Mullen]

Sorry Dave

 

I have no clue as to how to work with command lines. Unless you can point me at a tutorial somewhere?

 

I did try turning off the client with the command and was able to re-establish connection with the client. I did this after I had unsuccessfully gone through the Remove client, stop the engine, start the engine,and try to add the client. Although the client became available by broadcast, after restarting the client, I added it by IP just to see an alternate connection method might hold up.

 

As you pointed out this thread is getting pretty convoluted so my latest mind altering experience with Retrospect will be posted elsewhere. This thread has been very helpful in my use of Retrospect.

[CallMeDave]

I did try turning off the client with the command and [color:purple]was able to re-establish connection with the client[/color]

 

Uh huh.

[Bill Mullen]

I need to clarify my use of command. What I meant to say was: I turned off the client by holding down the command key while selecting off for the Retrospect client from the client machine.

[CallMeDave]

Yes, it was clear.

 

What was also made clear is that deleting the client from Retrospect was unnecessary all along.

 

Whatever the issue is, it's Client software based and not Engine or Console based.

[Bill Mullen]

I would say that remains to be determined, since the time I did restart the client using the command key to stop it, I had already gone thru the Remove client, stop engine, start engine steps. I'm sure I will have the opportunity to restart the client without touching the engine in the near future. Although if I don't have the opportunity I will post the success.

[CallMeDave]

I had already gone thru the Remove client, stop engine, start engine steps.

 

But you stated you did this "unsuccessfully."

 

If the problem was still evident before you tested the client process restart (thus leading to the recognition that efforts to solve the problem were not successful) it would seem likely that the work done at the Engine side was not related to the fix.

 

Certainly more methodical tests can help; future reporting may lead to a greater understanding of the issue.

[Bill Mullen]

I agree. Had I received your directions for turning the Client off a few minutes sooner I would not have attempted a fix with the engine. I look forward to reporting that the client restart fixes the issue. Should know in a few days. But I hesitate now to draw that conclusion as there were many occasions in the past where I was able to reconnect by the removing client process. The client is scheduled for a backup at 2:30am tomorrow. If history repeats itself the three backups that run on the server will be executed and the client will have not been visible on the network.

 

[Bill Mullen]

I have not lost contact with the client since the client was stopped and started and added via IP (not broadcast).

Thanks for the direction.

[Bill Mullen]

Looks as if Stopping and restarting the client works.Thank You,

Would it be difficult for you to explain how this can be accomplished via command line?

[CallMeDave]

sudo launchctl unload /Library/LaunchDaemons/com.retrospect.launchd.retroengine.plist

 

sudo launchctl load /Library/LaunchDaemons/com.retrospect.launchd.retroengine.plist

 

Oops; sorry. That's the engine (uses 21st Century launchd)

 

The client process is retroclient; so you can "kill" by PID or "killall" by name.

 

The retroclient binary lives at:

 

/Applications/Retrospect\ Client.app/Contents/MacOS/Resources/retroclient

 

Sorry I can't remember how to start a process without it being attached to the shell; Russ?

Edited March 13, 2010 by Guest

[rhwalker]

sh$ /Applications/Retrospect\ Client.app/Contents/MacOS/Resources/retroclient &

 

The "&" at the end of the command, just before the carriage return, runs the command as a background process.

 

In case it isn't clear, the "sh$" is the shell prompt, not part of the command.

 

Russ

[Bill Mullen]

Russ/Dave,

Fraid you are talking to a rank amateur here. I have figured out how to open terminal, which I guess is where these command lines go.

 

So if I enter:

 

"sh$ /Applications/Retrospect\ Client.app/Contents/MacOS/Resources/retroclient &"

 

into terminal on the host machine is this going to turn the retrospect client off in the client machine?

 

Or do I type:

 

"sh$ kill/Applications/Retrospect\ Client.app/Contents/MacOS/Resources/retroclient &"

 

followed by:

 

"sh$ start/Applications/Retrospect\ Client.app/Contents/MacOS/Resources/retroclient &"

 

I assume that the objective here is to stop and start the client remotely, saving me a trip to the client and also saving my marriage by reducing the number of times I have to ask my wife to let me interrupt her forever photo editing and use her machine to perform some perceptively useless tweaks.

 

My terminal prompt looks like this:

 

Last login: Thu Mar 11 21:10:47 on console

You have mail.

[bill-Does-Computer:~] billdoe%

 

Name has been changed to protect to under-informed.

 

 

 

[rhwalker]

Russ/Dave,

Fraid you are talking to a rank amateur here. I have figured out how to open terminal, which I guess is where these command lines go.

Ignorance is not an embarrassment - we were all ignorant once, and many still are.

 

I apologize if my post wasn't clear. I tried.

 

The "sh$" is the shell prompt, similar to your "billdoe%" prompt. You don't enter that, it is printed at the start of the line.

 

The command to enter (best to cut and paste because of the escaped space in the middle) is:

 

/Applications/Retrospect\ Client.app/Contents/MacOS/Resources/retroclient &

I was responding to Dave's request for how to [color:red]restart[/color] the client after it had been stopped using the kill command.

 

Dave gave the command to stop the client, but a nicer way is to send the client a HUP signal (hangup, or kill -1 or kill -HUP) so that it can clean things up nicely when it quits, rather than just force terminating the process (kill -9).

 

Those are the signals to send to the retroclient using the "kill" command.

 

You might enjoy reading the manual pages for the shell (man sh) or for the kill command (man kill).

 

So if I enter:

 

"sh$ /Applications/Retrospect\ Client.app/Contents/MacOS/Resources/retroclient &"

 

into terminal on the host machine is this going to turn the retrospect client off in the client machine?

no, it will restart the client (well, you don't enter "sh$" - that's the shell prompt). See above.

 

Or do I type:

 

"sh$ kill/Applications/Retrospect\ Client.app/Contents/MacOS/Resources/retroclient &"

 

followed by:

 

"sh$ start/Applications/Retrospect\ Client.app/Contents/MacOS/Resources/retroclient &"

Neither. The first has three problems: (1) you don't type the "sh$" shell prompt; (2) will result in a "file not found" because there is no space after the kill program name, so the shell tries to use the line to find the retrospect client in a kill subdirectory of whereever you type the command or your current $PATH variable; and (3) Even if you had the space after "kill", it would do the kill in the background (because of the &), but you need a process ID (see Dave's post) to do that. The kill shouldn't be done as a background process.

 

You can get the process ID by:

ps axlwww | fgrep retro

 

The line with retroclient at the end is the one you want.

 

the first number printed is the User ID; the second number printed is the Process ID (PID).

 

I assume that the objective here is to stop and start the client remotely,

Yep.

 

To stop the client (at least how I would do it):

ps axlwww | fgrep retro

 

then, using the second number printed on the line ending with retroclient (let's assume the number was 1776 - but note that it will be some different number):

 

sudo kill -1 1776

 

if the fgrep still shows retroclient running, then do:

 

kill -9 1776

 

Then, to start the client:

 

/Applications/Retrospect\ Client.app/Contents/MacOS/Resources/retroclient &

 

By specifying the entire path, you can type that anywhere. The default, when you start a shell, is to start it in your home directory (usually, /Users/ShamroxBill (or whatever)).

 

You could confirm the correct command to restart the client by reading the RetroClient shell file in /Library/StartupItems - actually, it's the RetroClient file within the RetroClient directory in /Library/StartupItems

 

That's how the system starts it on startup.

 

You can read that file by the following command:

 

cat /Library/StartupItems/RetroClient/RetroClient

 

I think you can figure it out from here.

 

Post again if still confused.

 

Russ

[Bill Mullen]

OK, so an old dog can learn some new tricks. But I can't get past the last one.

 

I can get into my clients shell at the user level or at the next highest level with the sh command.

 

I have successfully retrieved the process number and with that turned off the client at both levels.

 

Then due to operator error I had to restore the entire client from a recent clone. and for whatever reason a Known_hosts file kept me locked out of accessing the restored client until I learned how to edit the known_hosts file. That done I'm trying to turn Retrospect client back on using the command:

/Applications/Retrospect\ Client.app/Contents/MacOS/Resources/retroclient &

 

I get the "/Applications/Retrospect\ Client.app" by dropping the retrospect application into the Terminal window so it probably is OK. Then by getting the contents of the client I can complete the path just as you describe. But the result I get is:

 

I enter (just what is inside the parentheses):

sh-3.2$ "/Applications/Retrospect\ Client.app/Contents/MacOS/Resources/retroclient &"

 

This is returned:

[1] 2894

sh-3.2$ sh: /Applications/Retrospect Client.app/Contents/MacOS/Resources/retroclient: No such file or directory

 

Or I can do the same from the user shell:

 

I enter:

Freida-Does-iComputer:~ freidadoe$ "/Applications/Retrospect\ Client.app/Contents/MacOS/Resources/retroclient &"

 

This is returned:

[1] 2901

Freida-Does-iComputer:~ freidadoe$ -bash: /Applications/Retrospect Client.app/Contents/MacOS/Resources/retroclient: No such file or directory

 

I have tried different paths to the application as opposed to the exec file "retroclient" in the resources to no avail. I do notice that a forward slash has been removed from the returned statement.

 

I seem to have exhausted my ideas at this point. Just figuring out how to find and edit a file buried somewhere deep inside unix was a monumental achievement for this old timer.

 

[rhwalker]

my mistake, sorry old dog. With various versions of the Retrospect client, things move and are renamed.

 

do the following command in Terminal:

 

cat /Library/StartupItems/RetroClient/RetroClient

 

The next to last line (just before the "fi") will have the command that you want to execute. That's how the client starts on boot. Whatever that says, that's what you want to do.

 

Russ

[Bill Mullen]

Thanks!

It works!

 

I should have seen that there was no MacOS in the path to retroclient when I opened the contents.

 

I appreciate your persistence.

 

Maybe the next release of the client will work all by itself.