Proactive backup "needing" offline media

[fredturner]

Hey Guys 'n' Gals--

 

Didn't know whether to dredge up an old, similar post or start a new one, so I started a new one, and will reference the old:

 

http://forums.dantz.com/showtopic.php?tid/32118

 

While the OP in that thread is using a tape library, I'm seeing similar behavior using FireWire disks. Basically, it appears that threading is "helping" the Proactive Backup routine to want media sets that are offline. Here's what happens:

 

I have a proactive setup to back up multiple network clients to redundant Media Sets A, B, and C. I rotate these sets/drives weekly, so one is attached at all times. What I'm seeing is that if Client1 is backing up to Set B (which is online), the proactive script will concurrently try to back up Client2 to Set C (which is not online). Of course, once this happens, I get the tapes-with-flashing-question-mark icon as Retrospect thinks it "needs media" for Set C.

 

The point, of course, is that the Proactive server is supposed to be using whichever Set is available from those specified in the script, NOT asking for offline media (as you'd expect from a normal backup script w/o it's scheduled media). Should I report this in the Bug forum? Is there a workaround (I can hit Stop and then delete the entry in the Activity list, but I don't consider that much of a fix) to keep this from happening?

 

Thanks,

Fred

[Tree]

I haven't actually been using proactive scripts, so take this all with a hefty grain of salt. But my understanding is that a proactive script looks for an opportunity based on when the client is available, having nothing to do with which media set is available. If your script says to proactively backup clients 1 and 2, each to Media Sets A, B, and C, then whenever 1 or 2 is available it will attempt to perform backup to all of those sets. With one or more sets offline, you will be prompted for the media.

 

What you're seeing is likely that the second action starts concurrently, using the other media set, simply because RS8 can "thread" its activities thusly. In other words, Client 1 to Media Set A can run at the same time as Client 2 to Media Set B. But backups to the same Media Set cannot run simultaneously, so if both 1 and 2 are available and hence RS8 wants to back them up, it will be forced to send them to different Media Sets.

 

Or rather, not forced so much as take the option you've given it, by including all the Media Sets in the same proactive script. So, one way to control things might be to set up three proactive scripts, corresponding to the three Media Sets, so that when RS8 is executing a given script it only has one target Media Set to which it can send data, which would force it to queue up the backups in sequence (i.e. Client 1 gets backed up to A, then Client 2 gets backed up to A, non-simultaneous).

 

What I do not know is whether and how one might schedule such proactive backups, so that each one is only active during the time frame that the corresponding Media Set is actually online. But I bet this can be done! I'll leave it to others to fill in where I am ignorant, or perhaps this gives you enough to chew on that you figure out a workaround on your own. If you do figure out the "right way" to accomplish what you're after, be sure to post here so we can all learn from your example.

[rhwalker]

my understanding is that a proactive script looks for an opportunity based on when the client is available, having nothing to do with which media set is available.

Not quite. You might want to check out pages 128-131 of the Retrospect 8 User's Guide.

 

Proactive Backup starts at the top of the volumes queue, determining the availability of each source volume and, if there is a choice, backing up each to its most suitable Media Set. ...

Copies to the most ideal available Media Set in the destinations list. Automatic media rotation among multiple available Media Sets.

When it works, it's really nice for resources and clients that appear and disappear.

 

Right now, it's hard to distinguish correct operation from incorrect operation because of bugs.

 

Russ