R7 MS, Proactive not auto-starting

[awnews]

+ Retrospect version 7.0.249 (MS and Value Pak, so Proactive and other options)

+ Retrospect Update, version 7.0.1.103

W2K Server SP4

Dual-proc 500MHz PIII, 512M RAM

 

I'm running the new Retrospect 7 (multi-server), jumping in earlier than I normally would with a new release but I wanted to take advantage of the new grooming features (comment: On the otherhand I now have to "convert" about a hundred File backups to Disk Backups since Grooming doesn't work with File, and a Proactive Recycle feature was not added to R7. At least Disk backup setup now allows me to specify a save location when creating it).

 

As I was working with the program and running a client backup, the program crashed (in a "friendly" manner, telling me that it had an error and would like to send off an "assert..log" file. I said OK but don't know if it went). After I restarted the program, it asked me if I wanted to run Scheduled executions and I clicked "no" (thinking it was trying to run a time-scheduled backup in error). After this, I noticed that Proactive did *not* restart when the program did and I had to start it manually. However, if I quit and restart Retrospect, the Proactive backup does *not* restart (==stopped state) and *each* time I have to manually click on the "Start" button. Even then, the status in the Proactive tap says "Defer" and the status info of that pane says "Execution is deferred." And even *then* it doesn't seem to be running any Proactive backups, even when I "schedule" one for a few minutes in the future.

 

I'm running with the Retrorun Launcher service disabled (had found it unreliable with Retrospect 6.5 so I just left the program running all the time).

 

What do I need to do to get the program to again Start the Proactive feature on startup and remove the "Defer" state?

[awnews]

Not only does Proactive no longer auto-start (even after a reboot) but...

 

As far as I can tell, even when I start Proactive manually, no Proactive backups seem to be run. I changed some Proactive backups from File to Disk by removing the old File set and creating a new Disk backup set. The Proactive script shows as "ASAP" (with no previous backup) but no backup ever starts. And even if I assign a Schedule to this (e.g. a few minutes in a future), the Proactive backup never starts but merely reverts to "ASAP" after the scheduled time.

 

On the Proactive not auto-starting, I tried enabling the Retrospect Launcher, and it did create the "Retrorun" process. But after quitting Retrospect, Retrospect did *not* auto relaunch to turn Proactive back on (as it did with Retro6.5). So I've turned the Launcher back on and manually restarted Proactive (not that it seems to be doing anything...). It will be interesting to see if Retrospect runs any of the time-scheduled jobs overnight.

 

As I noted before, the Proactive Action status is "Deferred" and the lower right status is "Execution is Deferred." The Proactive setup is sure acting like it's been suspended, but I can't find any global or script-specific setting that would do this or a way to turn it back on.

[awnews]

This morning, after I found that Retrospect hadn't run any scheuled jobs either, I kept poking around until I found the little "Stop all execution activity" button in the menu bar [it was on]. I had never used this before [was it in R6?] and had never set it intentially, so I'm wondering if it got set by the R7 crash.

 

In any case, this should be better highlighted, e.g. by *also* making it a check-marked item in the Run menu (*above* the "Stop Proactive Backup" item--this would be much more "symmetric"), making it *blink* in the menu bar, having it add a messsage to the log when it's turned on and off, etc.

[awnews]

So to wrap this up:

 

The "Stop execution" toolbar button is new in Retrospect 7. It wasn't in Retrospect 6.

 

I believe that it got turned on after the program crashed when I started it up again and it asked me a question (which I didn't read carefully and didn't understand) about stopping scheduled backups. It was misleading since there weren't any *scheduled* backups, only *Proactive* backups, running at the time of the crash so I accepted the default "yes."

 

The documentation vs. program operation is wrong, misleading and inconsistent in this area. The menu button and new R7 manual refer to the button as a "Stop all execution" or "Stop button" toolbar button. But every program status message (above Proactive pane, lower corner of program, Scheduled pane, etc.) referred to the status as "Deferred." If you do a search on "Defer" (which I did) trying to diagnose the situation, it takes you to irrelevant areas concerning a client "Deferring" Proactive backups. And "Defer" is temporary and/or implied that the program will try again latter--this button *permanently* stops/halts execution until it is pressed again--so "Defer" is the wrong status to assign to this situation.

[natew]

Hi GoAWest,

 

Sorry to leave you hanging on this one. I was away for a bit.

We have noted your comments about the confusing terminology.

 

Thanks

Nate

[DantzEvangelist]

My Dantz Retrospect 7.0.249 MultiServer also hung and I am having the same trouble, and this fixed it. Here's a few more details.

 

On my WinXP TabletPC (with everything but SP2 which corrupts my Outlook), I just installed Retrospect 7.0.249 MultiServer yesterday to test it out (but without the latest driver update -- because of it's confusing name, but then again I was using a Memorex 3202-3282 (2.4x DVD+R DL burner) SNCFAJ445401501, which wasn't added by these drivers).

 

I backed up DVD+R 1 of 2 with no problem, leaving the computer idle overnight. In the morning, I started DVD+R 2 of 2, then began to work on other stuff while Retro continued in the background. Then I noticed Retrospect had been hung for a good hour or 2. The drive light was also blinking steady (1/2 sec on, 1/2 sec on). Pressing the eject button did nothing, logging out wouldn't quit Retro (logout stopped there), so I had to kill Retro. And then on restart of my computer (just to be save), I got a blue-screen instead of a proper shutdown:

`shutdown to protect your computer. \ PROCESS_HAS_LOCKED_PAGES \ … \ STOP: 0x00000076 (0x00000000, 0x860212C0, 0x00000001, 0x00000000) \ …" and had to hard reset the computer.

 

On reboot, Retro seemed to work normal but now wouldn't start any automatic backups, just as GoAWest describes. Indeed, I noticed that under Activity Monitor->Proactive "Don't allow scheduled and waiting executions to start" is checked and grayed out, and (consequentially I would suppose) backups wouldn't run. I searched Google for this error message and couldn't find anything. It was only later when I noticed that in the Retrospect status bar it said "Execution is deferred" and searched Google for "Retrospect deferred" that I ran across this post (immediately). I'm including the above error situation descriptions (the grayed out text) so other users will find this posting when they search Google.

 

Then reading the postings, I found the "Stop all executions" button (red circle with an X in it) in the toolbar, which GoAWest describes, clicked it, and all was back to normal.

 

Dantz, things to fix:

(1) after a crash, do not select "Stop all executions" - or if you do, display a warning each time Retrospect is launched warning that this is set.

(2) as would be obvious good UI design, whenever you make any option unchangeable (typically grayed out), please include and link (or explanation) entitled "why is this unchangeable/grayed-out"! Without this, it is quite frustrating and a silly waste of everyone's time.

 

Thanks much to GoAWest for documenting this problem and posting the solution. Hope these additional details (especially search keywords) help others from having to go thru the same frustration.

 

After clearing "Stop all executions", Proactive backup continued, but then, going to review my selectors while the backup was running, the computer blue screened from the the same error message as above, and required a hard-reset (this time, at a poor time, causing mee to loose some MS Office documents I was working on!). Moreover, after the computer's Windows XP startup screen, the screen went blank and the computer wouldn't boot. I had to unplug the USB devices (including the DVD drives) from the notebook before I could boot as normal. After I logged back in, I plugged in the USB devices, but still none of my DVD burning applications would come up, and indeed, "My Computer" wouldn't browse the drives. Looking at the Memorex 3202-3282 DVD drive, the light was steady blinking as before. After power cycling it, things went back to normal. While I first thought this new version of Retrospect might be causing these unexpected blue screens, I'm now thinking it's the Memorex 3202-3282 SNCFAJ445401501 drive firmware or drivers. Checking the drive's official URL, http://www.memorex.com/html/products_detail.php?section=3&CID=11&SID=15&PID=782&FID=115&opento=11, there is an firmware update: BWSE, but I already have it (downloaded and verified). My suspect is the drive has a bug which causes WinXP with all updates except SP2) to blue-screen, and this is triggered by Retrospect 7.0.249 burning to a DVD+R while there is some activity going on the background (and perhaps other things). At this point, I blame the drive, and am planning to return it.

 

Though this doesn't mean Dantz can't do the fixes above. Hope this helps.

 

-Mike Parker, small business networks, resume at www.Cytex.com/go/MBParker/Professional

[XOR42]

Same for me. After being away for 2 weeks, I saw an email form this forum about the "little red stop" button. I took a look at my R Pro 7.0 logs and discovered I had NO BACKUPS for 2 weeks!!!! There were NO ERRORS in the logs. Just NO BACKUPS!!! I then saw the "deferred" message, as well.

 

As a s/w designer, I find it unconscionable that a full version of an upscale back up prgram would turn itself OFF without warning or logged error! This needs to be fixed ASAP! As per other suggestions here, you need to add the following to the very next update:

 

1. If Retrospect is ever placed into STOP mode, you need to log that action with details of who stopped it and the reason. If Retrospect, full details of the error that triggered it. If the user, then "as requested by operator".

 

2. Add a pop up that says something like:

WARNING: Retrospect has been stopped ("by the operator" or "due to a serious error") and will not perform any further scheduled backups until backups are re-enabled. See the log for details. To resume backups, resolve any errors that exists then re-enable backups using the start/stop option.

 

3. Always Autostart When Scheduled

Whenever there are any active schedules defined but Restrospect is in STOP mode, you need to start Restrospect at the scheduled time but pop the warning noted in item #2 above so we can see the darn problem as soon as we look at the screen.

 

4. Constant Operator Oversight and Bugs

Retrospect needs to more closely adhere to the design goal of NOT requiring constant operator oversight. We pay good money for the full Retrospect product to confidently RELIEVE us of that requirement. As it stands, we have to check the logs DAILY, read this forum constantly to find problems we did not know we had, apply any updates ASAP, and still have to fear our back ups may have not run or will fail on restore.

 

EMC/Dantz needs to seriously re-evalute the design. I would have come down very hard on my Design and Q/C teams if they ever allowed such anomalies of usablilty and reliability in one of our products.

 

In the 6 months I have been using R7x, I have spent literally 100's of hours dealing with issues such as the following:

1. trying to get it to install and work properly

2. debugging numerous new and onging issues

3. rebuilding failed backups

4. no apparent way to fully verify (byte level) the integrity a backup set versus teh current system state.

5. inability to create recovery CD from OEM OS CD's. Like, every modern PC has an OEM OS CD not a retail MS CD.

6. living with the failed comparison bug that EMC still has not fixed

7. No apparent way to get a scheduled groom to run when back sets are PWD protected. Fails with "can't enter password here" kind of message.

 

And more. These issues are all the more poignant since I am running a very standard scenario of XP-SP2, 2 Maxtor USB drives, and two basic backups sets. No unusual OS, drives, or devices.

 

You need to let us know that EMC is acknowledging reported bugs, the weight they are assigning to them, and some minimal form of estimated time-to-fix. Hearing indirectly and unofficially in this forum from those that work at EMC/Dantz doesn't really cut it. It only suggests (hopefully incorrectly) that EMC does not have the resources or the interest to support the product.

 

With all the best of intents!

[XOR42]

Sigh ... after revewing numerous comments on the subject of Groom and the lack of responses threreto, I fear that Groom is another major and necessary feature that, well, just doesn't work!

 

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

1. Groom out of space when 175% available!

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

When my backup set and drive has about 175% of the space occupied by the data to be backed up, Groom fails with an out-of-space error. The data being backed up only consumes 20GB raw! The backup set is allocated to 31 GB. The actual backup drive has 32 GB free. I am also using backup compression so the requirement is actually LESS than 20 GB. What gives!!!

 

I have never been able to groom any of my backup sets when grooming was needed. The backups just keep growing until a Groom is triggered and then it fails due to lack of space! Just how much space do we need for a back up and for groom to work! Perhaps we need 200% 300%? That would be insane! I am now in my 6th month of trying to get R7 to work without crashing evenutally on space and other issues.

 

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

2. Groom cannot be scheduled with passworded backup set

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

Groom has a major fault in that it will not operate on a back up set that is password protected. It aborts with an error message similar to "no password - cannot enter password here". It seems to suggest that although the password is known and saved by the scheduler (pwdds DO work with reg b/u's), the Groom schedule task cannot accept and or appy the same password. As such, Groom cannot be scheduled! When run manually, a password is manully entered and it works. However, as per item #1, manual Grooming only works when a Groom is NOT needed. That is, when there is a HUGE amount of free space available (200-300%) and you run it just for kicks to see it works.

 

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

This will be my 3rd or 4th mention of these problems in 6 months. There does not seem to be any answer. Can anyone testify that Groom DOES work and, if so, how do you set up the password? And if so, then with what percentage of the required space on the target back up drive free? 100%, 150%, 200%, 300%???? Please? Anyone?

 

Thanks