Hello,
in message <[EMAIL PROTECTED]> you wrote:
>
> It will be slower, but perhaps not by a lot. It will likely be much faster
> than if you simply ran 3 simultaneous jobs without spooling, and the total
> backup time should be shorter with simultaneous spooling than running one job
> after a
On Tuesday 21 February 2006 21:30, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> > C) You run multiple jobs in parallel and want to keep jobs together on
> > tape (to allow much faster restores, usually).
>
> How exactly is this working, especially when the spool size is
Hello,
On 2/21/2006 9:30 PM, Wolfgang Denk wrote:
In message <[EMAIL PROTECTED]> you wrote:
C) You run multiple jobs in parallel and want to keep jobs together on
tape (to allow much faster restores, usually).
How exactly is this working, especially when the spool size is
smaller the
In message <[EMAIL PROTECTED]> you wrote:
>
> C) You run multiple jobs in parallel and want to keep jobs together on
> tape (to allow much faster restores, usually).
How exactly is this working, especially when the spool size is
smaller then each of the backups?
Let's say I have 3 jobs "
On Tue, 21 Feb 2006, Ryan Novosielski wrote:
What are the requirements for such a situation? They must be A) simultaneous
and B) concurrent jobs must be set to more than one and C) the backups must
write to the same tape in the pool?
Yes, however it's useful if there are multiple drives too.
Hi,
On 2/21/2006 5:22 PM, Ryan Novosielski wrote:
What are the requirements for such a situation? They must be A)
simultaneous and B) concurrent jobs must be set to more than one and C)
the backups must write to the same tape in the pool?
My view of this topic is the following. Spooling is re
What are the requirements for such a situation? They must be A)
simultaneous and B) concurrent jobs must be set to more than one and C)
the backups must write to the same tape in the pool?
_ _ _ _ ___ _ _ _
|Y#| | | |\/| | \ |\ | | | Ryan Novosielski - User Support Spec. III
|$&| |
On Mon, 20 Feb 2006, Dan Langille wrote:
IMHO, spooling only really makes sense if your incoming data cannot
keep up with the tape drive.
...or if you are making multiple simultaneous backups...
AB
---
This SF.net email is sponsored by: S
On Mon, Feb 20, 2006 at 11:36:45PM +0100, Ludovic Strappazon wrote:
> Wolfgang Denk wrote:
> >And assuming you are backing up some big RAID array it might be
> >difficult to provide big enough spool files.
That's certainly the case in my situation. I don't have 4 TB sitting
idle that I can
On 20 Feb 2006 at 16:51, John Kodis wrote:
> To my surprise, it took over twice as long to perform a full backup
> when spooling was enabled. The numbers for two full backups made two
> weeks apart are:
>
> Without spooling: 3.8 TB in 24:57 at 44.8 MB/s
> With spool file: 3.9 TB in 55:4
Wolfgang Denk wrote:
In message <[EMAIL PROTECTED]> you wrote:
However, much of the reason you'd want to spool is to limit the amount
of time that the client system is affected by a backup. Unless I'm
mistaken -- which is quite possible -- the machine spools much more
quickly than it would
In message <[EMAIL PROTECTED]> you wrote:
> However, much of the reason you'd want to spool is to limit the amount
> of time that the client system is affected by a backup. Unless I'm
> mistaken -- which is quite possible -- the machine spools much more
> quickly than it would be able to write t
However, much of the reason you'd want to spool is to limit the amount
of time that the client system is affected by a backup. Unless I'm
mistaken -- which is quite possible -- the machine spools much more
quickly than it would be able to write to tape, and then the RunAfterJob
script can run m
13 matches
Mail list logo
