I've got around this in the past by doing what you alluded to -- setting up 
multiple client resources (same hostname/system), one with the short-running 
savesets in say a daily savegroup, and another client resource with the 
long-running savesets in a different savegroup that runs every 3-4 days, for 
instance.

Each group will run independently; they'll obey the common parallelism 
directive for the client (which you do have to set high enough to run at least 
one of the short savesets if all of the long-running savesets are going), and 
you get your more-frequent small saveset backups to complete while the 
longer-running savesets toil for however long they take.

-dalvenjah


On Sep 4, 2013, at 5:38 PM, George Sinclair - NOAA Federal wrote:

> On 2013-09-04 18:40, Davina Treiber wrote:
>> On 22/08/13 22:04, George Sinclair - NOAA Federal wrote:
>>> Kind of a dumb question, or rather looking for confirmation here, but do
>>> save sets get backed up in the order that they're listed in the NSR
>>> client resource? I'm assuming that you've enumerated them and not used
>>> "All". My observation is that they do appear to be getting backed up in
>>> the order listed.
>>> 
>>> If not, is there a way to control the order other than splitting them
>>> into different groups/start times or manually running the save
>>> operation, from the client side, against each of the save sets in the
>>> order that you want them backed up?
>> Why would it matter?
> I don't recall the exact reasons now, but it seemed important at the time. I 
> think it had something to do with a situation wherein you have, say, a group 
> with several save sets, and due to the large number of inodes being used by 
> one of those paths/directories/file systems then if the backups started on 
> that one first (especially during a full) then the other save sets might just 
> sit idle (depending, of course, on the sundry parallelisms). This creates a 
> problem because they might not get backed up for a quite a while while the 
> other one is chugging away. As a result, the next time the group runs, it 
> aborts because an instance of itself is already running (natch). It could be 
> that the max parallelism has been reached (client, group, etc.), and the 
> other save sets can't send data, not for a long time. On the other hand, 
> while the converse situation, wherein the smaller ones go first, seems 
> identical in the end, I think I'd rather have the faster ones run first so if 
> I'm wai!
 ting on anything, it's the one that takes longer. At least everything else is 
done. This may be a poor explanation or example, but I didn't provide the 
background or justification in my post, so I'm not sure exactly what the 
scenario was. The obvious solution as far as the backups are concerned is to 
simply move the offender(s) to a separate group.
> 
> Or I may have been trying to troubleshoot the amount of time a backup group 
> was taking to complete wherein one or more of the save sets seemed to be 
> taking a very long time, forcing one or more of the others to pend, and I was 
> trying to corroborate the completion times reported from the media database 
> with the order that the save sets were listed for the NSR client resource.
> 
> George
> 
> 
> 
> -- 
> George Sinclair
> Voice: (301) 713-3284 x210
> - The preceding message is personal and does not reflect any official or 
> unofficial position of the United States Department of Commerce -
> - Any opinions expressed in this message are NOT those of the US Govt. -