* Alan Brown

> Don't let on how easy individual file restores are, else you'll be 
> constantly handholding the worst idiot in your group.
> 
> You know the one - doesn't make backups, wiped all his files, wants
> them back yesterday..... and then repeats the exercise every week.

No problems delaying that kind of restore jobs.  Fortunately my
colleagues are quite clueful so I don't really have a problem with them
wiping their own files every other day...

We're a service provider (hosted applications and so on) so most of the
backups are of customer data.  So the restore jobs I'm talking about is,
say, if a customer database has crashed, their precious web site,
mailserver, or whatever is down, and the SLA clock is ticking - if we
can't bring their service back online in 60 minutes they don't pay.  So
the restore job needs to run as quickly as possible - and that's final.

Waiting for one job to finish (or having to cancel only one job) before
the restore process starts is OK.  Having to cancel all running jobs
(which might have been at it for hours) to get the restore job going
sucks.  The best would be if there was always a free slot dedicated to
restore processes, come to think of it.

> Understood. For my situation I use different pools for those jobs and
> a multiple-drive autochanger. That way the slow jobs can keep
> lumbering on while the fast jobs execute on other hardware.

Hmm, that might work, yes.  I'll look into it.  Thanks.

Best regards,
-- 
Tore Anderson

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users