On 2013-09-04 21:21, Dalvenjah FoxFire wrote:
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
Yes, that's something I've had to do, too, as well as moving the fulls,
for the more egregious offenders, up or back one or more days in order
to better accommodate them and give them more time to complete so they
don't push too much beyond the allotted time and/or for more parallelism
to the drives. For example, in the case of the later, maybe I'm
staggering the start times for fulls, but maybe group A always starts
too late, so by the time it's finally running, most of the other fulls
have completed, and there may not be enough save sets in group A to
really push the drives, so the drive(s) aren't writing as efficiently.
But moving the start time for group A back a day might be better so more
of the time is spent in conjunction with other fulls so the drives
stream better. Of course, at some point, somewhere, you end up with a
single full backup save set running, and with nothing else writing to
that pool, the tape drive slows considerably.
I think the answer to Davina's question is simply 'no', it doesn't
really matter except maybe in cases where you want to give preference to
certain save sets that might otherwise be forced to wait for an
unacceptably long time, but clearly, there are workarounds.
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 wa!
iting 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. -
--
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. -
|
