Jump to content
PitterPat

Proactive jobs try to run with no availabe backup set

Recommended Posts

Hi,

 

II've got three external drives for bacups which I rotate. Only one is connected at any time.  Each drive has a unique backup set name (bu1, bu2, bu3).

 

Similarly, I have three proactive jobs (job1, job2, job3).  The jobs are identical except each has it's own unique destination (bu1..bu3 respectively).

 

But since moving to a new PC jobs are starting to run even without the assosiated backup set connected.  I then get a dialog asking me to locate the missing backup set.

 

This never happened on the old PC.  After all, isn't that the whole idea of proactive backups; that jobs don't start till all the necessary components are available?

 

The Activity Monitor/Proactive/Backup Sets  always shows one external drive as ready while the other two have status of "Media".

 

What's going on.  Can I fix this?

 

Thanks,

 

PP

Share this post


Link to post
Share on other sites

There is a chapter in the manual about moving to a new PC. Did you follow all instructions?

 

It should work, so I don't really know what else to say.

 

Perhaps it will settle down once you have backed up at least one client to each backup set (and its member disk)?

You could disable two script temporarily and only use the script that runs against the attached disk.

Share this post


Link to post
Share on other sites

There is a chapter in the manual about moving to a new PC. Did you follow all instructions?

 

It should work, so I don't really know what else to say.

 

Perhaps it will settle down once you have backed up at least one client to each backup set (and its member disk)?

You could disable two script temporarily and only use the script that runs against the attached disk.

Hi,

 

Thanks for the feedback.

 

I originally followed the instructions for moving to a new PC but had all sorts of problems (previously discussed) so I scrapped everything and reinstalled fresh; created new jobs, etc.; and upgraded to a newer version (7.7).

 

Everything works other than the problem discussed here.

 

I'll wait for a couple of cycles to pass as you suggest and hope it settles down.

 

Thanks,

 

PP

Share this post


Link to post
Share on other sites

You don't actually need to have a Proactive Backup script for each Backup Set. With Proactive Backup Scripts you can assign multiple Backup Sets as the destination for the script. Retrospect will then use whichever Backup Set is available when the script runs. (See Retrospect User Manual for more details.)

Share this post


Link to post
Share on other sites

You don't actually need to have a Proactive Backup script for each Backup Set. With Proactive Backup Scripts you can assign multiple Backup Sets as the destination for the script. Retrospect will then use whichever Backup Set is available when the script runs. (See Retrospect User Manual for more details.)

That's very interesting.

 

Thanks!

Share this post


Link to post
Share on other sites

You don't actually need to have a Proactive Backup script for each Backup Set. With Proactive Backup Scripts you can assign multiple Backup Sets as the destination for the script. Retrospect will then use whichever Backup Set is available when the script runs. (See Retrospect User Manual for more details.)

Hi,  I tried this and it works BUT, each subsequent backup starts a bit later than the previous.  Eventually, we'll reach the time out time (backups are scheduled to run each night) and that means a day will be skipped.  Not a good idea.

 

Thanks for the thought.

Share this post


Link to post
Share on other sites

HELP!  This problem continues and I have no solution.

 

The backup jobs ask for a backup set that isn't attached.  This blocks execution of the backup to the currently attached set.  Hence nothing gets backed up!

 

This is NOT the way I understand proactive backups work!  What am I doing wrong?  How do I fix it?

 

 

Thanks in advance,

 

PP

Share this post


Link to post
Share on other sites

Still don't understand why this happens.  I've used RS for several years and never saw this before.

 

That makes two of us, unfortunately. :(

Share this post


Link to post
Share on other sites

Hi,  I tried this and it works BUT, each subsequent backup starts a bit later than the previous.  Eventually, we'll reach the time out time (backups are scheduled to run each night) and that means a day will be skipped.  Not a good idea.

Try setting the repeat period to 23 hours instead of 1 day so backups will creep forward instead.

  • Like 1

Share this post


Link to post
Share on other sites

Still don't understand why this happens.  I've used RS for several years and never saw this before.

Which version of Retrospect are you using on which version of Windows?

 

I have noticed some changes to the behaviour of Proactive Backup in Retrospect 9.5 (possibly 9.0 as well) with regard to the schedule. In 8.x it was possible to change the scheduled stop time to a later time on the fly and the new stop time would be implemented immediately. However in 9.5 the Proactive Backup has to be stopped and restarted for the new schedule to take effect which is not much use if you want to extend the schedule to allow a running backup to finish as I could in 8.x.

 

What procedure to you adopt when you change the media? How is the media connected (USB, eSATA)?

Share this post


Link to post
Share on other sites

Which version of Retrospect are you using on which version of Windows?

 

What procedure to you adopt when you change the media? How is the media connected (USB, eSATA)?

RS 7.7 (Windows)

 

Just unplug one and plug in another via USB.  Since no backups are running during the day I'm not worried about corrupting anything.

 

Thanks for the feedback,

 

PP

Share this post


Link to post
Share on other sites

Just unplug one and plug in another via USB.  Since no backups are running during the day I'm not worried about corrupting anything.

It is always a best to eject/disconnect USB disks from within Windows before unpluging the disk (especially if write caching is not disabled). From experience I have found that if a USB disk is unplugged without ejecting it Windows can sometimes believe the disk is still connected. (USB disks that have spun down before being unplugged seem to be more prone to this behaviour.)

  • Like 1

Share this post


Link to post
Share on other sites

It is always a best to eject/disconnect USB disks from within Windows before unpluging the disk (especially if write caching is not disabled). From experience I have found that if a USB disk is unplugged without ejecting it Windows can sometimes believe the disk is still connected. (USB disks that have spun down before being unplugged seem to be more prone to this behaviour.)

Thanks for the input.  I'm going to try to find a scrip I can run via the Windows scheduler to do the job.

 

The problem for now is that the person tasked with swapping the drives is not intended to have access to the system.

 

Thanks again!

Share this post


Link to post
Share on other sites

Well I ran the job with

 

attachicon.gifSkärmavbild 2015-01-22 kl. 17.00.03.png

 

Set the media request timeout to 20 minutes (or less).

OK, I set the timeout to 10 minutes and got absolutley deluged with messages "The Backup Set member "1-MyPP2 (G)" is corrupt or has data from another set.       Media request for "1-MyPP2 (G)" timed out after waiting 0:10:00"

 

The BU set isn't corrupt, it's just not attached.

 

So the idea of setting the timeout is a good one but it comes with a cost.  All those messages makes it harder to find any "real" problems.

 

Still looking for a solution...

 

Thanks,

 

PP
 

Share this post


Link to post
Share on other sites

Thanks for the input.  I'm going to try to find a scrip I can run via the Windows scheduler to do the job.

 

The problem for now is that the person tasked with swapping the drives is not intended to have access to the system.

 

Thanks again!

I thought this was common knowledge.

http://windows.microsoft.com/en-us/windows7/safely-remove-devices-from-your-computer

Share this post


Link to post
Share on other sites

Well I ran the job with

 

OK, I set the timeout to 10 minutes and got absolutley deluged with messages "The Backup Set member "1-MyPP2 (G)" is corrupt or has data from another set.       Media request for "1-MyPP2 (G)" timed out after waiting 0:10:00"

 

The BU set isn't corrupt, it's just not attached.

 

So the idea of setting the timeout is a good one but it comes with a cost.  All those messages makes it harder to find any "real" problems.

 

Still looking for a solution...

 

Thanks,

 

PP

 

I'm quite sure this has something to do with just pulling the plug on the drive(s).

  • Like 1

Share this post


Link to post
Share on other sites

Yes, common knowledge but I didn't think if mattered in this case since all RS activite ceases at 6 AM and the drives won't be swapped till a few hours later.

 

But I did find a neat (a free) program to eject the dirve via a Windows scheduled task. 

 

See it here:  http://quickandeasysoftware.net/software/usb-disk-ejector

 

It has a gui but can also be run from the command line.  Very nice!

 

I've said this b4 but RS poactive BU should NOT be exhibiting this issue!

 

PP

Share this post


Link to post
Share on other sites

Yes, common knowledge but I didn't think if mattered in this case since all RS activite ceases at 6 AM and the drives won't be swapped till a few hours later.

When Retrospect activity ceases is less important than whether Windows recognises the change of disk. Even though the disk may have physically changed Windows can still believe the original disk is still connected if it was not ejected first.

 

I have experience this behaviour in Windows and is most common when the same USB port is used for both disks. From my observations this looks to be more a hardware problem because not all machines have this problem although they are all running the same version of Windows. I also suspect that the power management settings for the USB ports may also influence this behaviour.

 

But I did find a neat (a free) program to eject the dirve via a Windows scheduled task.

Definitely worth a try.

 

I've said this b4 but RS poactive BU should NOT be exhibiting this issue!

Retrospect relies on Windows for information of what media is connected. If Windows has the wrong information then Retrospect will fail. Edited by Scillonian
  • Like 1

Share this post


Link to post
Share on other sites

I have fallen foul of Windows issues around removing & ejecting media. I also agree that it is important that windows is correctly informed of the ejection.

I have found an excellent utility which helps tremendously with this issue, USB Safely Remove. Free trial and reasonably priced.

Maybe worth a try.  http://www.safelyremove.com/index.htm

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

×