Jump to content
tigerspy

7.7.208: Proactive polling not working right

Recommended Posts

Am running multi-server windows , update 7.7.208. I have several proactive backup scripts with lots of clients. The polling will start, but will hit a machine a few slots down the polling list, and gets a status of "retry", so the polling starts back up at the top. Polling never gets below that machine into other proactive scripts, so there's lots of machines on my network not getting backed up.

 

Advice?

 

Keith

Share this post


Link to post
Share on other sites

I should probably add that I haven't change anything to my proactive backup scripts. Everything was working OK in 7.7.203 (with the exception of crashing daily). Seems to be an issue with 7.7.208. I tried recreating my proactive scripts in 7.7.208 to see if could help. Nothing is helping.

Share this post


Link to post
Share on other sites

The behavior seems to be this:

 

It will allow one execution per proactive backup script (because I only have one backup set assigned per backup script). When it finds another available client to backup in the same backup script, it sets the status of "retry" , but instead of skipping over it to retry that client later, it just goes back to the top of the polling queue.

 

It's not just a specific client, because that "retry" client does eventually hit execution after the previous clients that took up the execution slot finished. Then when polling finds another client for that backup script that could be backed up, it hits retry and goes back to the top of the queue again.

 

 

Share this post


Link to post
Share on other sites

I seem to be having exactly the same problem - a "retry" causes it to skip back to the top of the list, so some users (like my own test account) never get backed up.

Share this post


Link to post
Share on other sites

I am experiencing this same issue. I call tech support almost daily for an update on the situation. Earlier today I was told the same thing I've been told for the past week: the engineers are aware of it, and it is a high priority bug.

 

-Sean

Share this post


Link to post
Share on other sites

Anyone heard any new news? I didn't notice this until today.

Basically instead of marking all of the clients in the same script as busy it just says retry when it hits a client in the same script as one that is already executing and then short circuits the polling to start over from the top.

I've tried manually deferring the client that causes it to short circuit and that doesn't help. It just ignores my deferral and does the same thing.

We're running 64 bit Retrospect on 64-bit windows XP.

Share this post


Link to post
Share on other sites

I'm also running 7.7.208 multi-server edition and have noticed this polling issue. To reiterate... server A belongs to backup set A-B and is currently executing. Server B belongs to backup set A-B and gets a retry status because backup set A-B is in use by Server A. Rather than polling Server C which belongs to backup set C-D (which is available for execution), polling starts over at the top of the list; Starting with Server A which is executing, so drops to Server B, getting a retry and starting over at the top of the list again. Server C of backup set C-D could be running as well as Server E of backup set E-F. But instead, only Server A is backing up because the polling issue.

Share this post


Link to post
Share on other sites

BUMP

 

Any plans for another bug fix soon? This is getting irritating. Also I believe I'm starting to have another issue that I read about, long match times. I came into work today and the backups that started Saturday night were still running with, supposedly, days remaining.

Share this post


Link to post
Share on other sites

If I had the budget, RS would be dropped by now. I would have paid twice as much for the 7,7 upgrade if it meant some resources would be put into testing and bug fixing.

 

I don't care if I have to patch the server one bug-fix at a time, I just need some improvement, it's been months now.

 

Light entertainment whilst we wait...

bug3.jpg

 

Rich

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×