Outstanding.
Thanks for posting the results. You've demystified a portion of the
Migration piece for me. :-)
Here's to many happy restores...
E~
On Feb 6, 2007, at 5:57 AM, Support wrote:
> Erich
>
> Thanks for the tips - I have just monitored tonights backups of
> incrementals and some ful
Erich
Thanks for the tips - I have just monitored tonights backups of
incrementals and some full backup of clients - all went well.
I configured one group of incrementals as a migration job and it went
without a hitch. The migration to tape was done after all other jobs that
wrote to tape after s
On Mon, 5 Feb 2007, Erich Prinz wrote:
> I have two FD which are set to MaxJobs = 1... this forces the second
> FD to wait in line until the first one completes.
It will also cause "status client = [N]" to wedge if there's a backup in
progress on that client (along with any attempts to use
bacu
Actually, the FD must also match the total number of concurrent
connections.
I have two FD which are set to MaxJobs = 1... this forces the second
FD to wait in line until the first one completes.
On the other 6 FD, the MaxJobs is set to 10. This permits all 6 to
run concurrently (provided t
There's a section on concurrent jobs in the Tips and Tricks section
of the docs.
Short version: each config file has an entry for MaxConcurrentJobs
= (or something like that) and each entry MUST be configured with
the identical number of concurrent jobs in order to work.
I've done this an
Hello,
How can I set up my storage and jobs so that I can have multiple jobs
writing to disk at the same, without having each job get its own file
device?
Thanks,
Brian - stealing threads in the dark of the night.
-
Using
