Hi,
07.02.2008 23:06, Steve Rippl wrote:
> We're running the same version of bacula-fd (2.2.4) on MS Server2003
> boxes (both the source and target for the backup/restore), and bacula-fd
> runs as SYSTEM.
Ok... I don't have a windows server 2003 for testing, and am not a
windows person, so this
You also might attempt to strip the E: prefix off the files before you
do the restore to the non E: drive.
-Jason
On Fri, 2008-02-08 at 14:20 +0100, Cesare Montresor wrote:
> A good test could be try restore in different (empty) directory,
> something like c:\tmp_bacula_re
A good test could be try restore in different (empty) directory,
something like c:\tmp_bacula_restore.
Just edit restore job before run.
Cesare Montresor
Steve Rippl wrote:
> Hi,
>
> First of all, great piece of software! Bacula has got us away from an
> expensive proprietary system (Commvault)
We're running the same version of bacula-fd (2.2.4) on MS Server2003
boxes (both the source and target for the backup/restore), and bacula-fd
runs as SYSTEM.
Hi,
07.02.2008 22:39, Steve Rippl wrote:
> Hi,
>
> First of all, great piece of softwar
Hi,
07.02.2008 22:39, Steve Rippl wrote:
> Hi,
>
> First of all, great piece of software! Bacula has got us away from an
> expensive proprietary system (Commvault) and we have something now that
> functions great on both our Linux and MS servers. I have a question
> though, running a restore on
Hi,
First of all, great piece of software! Bacula has got us away from an
expensive proprietary system (Commvault) and we have something now that
functions great on both our Linux and MS servers. I have a question
though, running a restore onto a different volume than the original
target is prod
