Hi again,
> I've noticed something strange after using the local fd on the
> director for verify.
>
> The first verify job fails with an bootstrap permission problem.
>
> 08-Aug 18:08 VU0EM005: Verifying against JobId=423
> Job=SMTCZB0003.2007-08-07_23.07.50
> 08-Aug 18:08 VU0EM005: Bootstrap r
Troy Daniels schrieb:
> > Now I've to find out what was going wrong with the two verify jobs of
> > my full backups from last weekend (mail from yesterday).
> >
> > The inc/diff verify jobs before were ok and the verify job of the inc
> > backup from this night too. Is there a way to rerun the ve
Hi,
>
>> I run my VolumeToCatalog verify jobs with my backup server specified as
>> the client to minimise Network impact for this reason.
>
> So the Client option doesn't have to be the same as the client name
> that was used for the backup? I've never thought about this.
>
Neither had I
Troy Daniels schrieb:
> > I need a clarification on how a VolumeToCatalog verify job works. Until now
> > I
> > thought this type of verify would read the attributes from tape (Volume) and
> > compares it with the attributes in the db (Catalog).
>
> Technically true, but I believe it's the file d
Hi,
Ralf Gross wrote:
> Hi,
>
> I need a clarification on how a VolumeToCatalog verify job works. Until now I
> thought this type of verify would read the attributes from tape (Volume) and
> compares it with the attributes in the db (Catalog).
>
Technically true, but I believe it's the file dae
Hi,
I need a clarification on how a VolumeToCatalog verify job works. Until now I
thought this type of verify would read the attributes from tape (Volume) and
compares it with the attributes in the db (Catalog).
But I see high network traffic between bacula-dir and bacula-fd on the client.
The le
