Subject: Re: [Bacula-users] Backup to remote cifs share

> Hey
> We have a few clients where we use bacula to make a backup to a remote
> cifs share (usually a windows fileserver).
> This is implemented as a File Storage device in the sd, with a
> mount = yes" and the necessary mount commands etc.
> Now this has never been an issue until last week when a client had DNS
> problems, the share wasn't accessible, and bacula decided to just fill
> the local disk.
> I had always been under the impression that a failure to mount would
> cause the job to fail? (and it has in some tests a few months ago if I
> recall correctly)
> It is probably worth mentioning though that in an effort to resolve
> early permissions problems I gave bacula permissions on the mountpoint
> itself (/mnt/bacula).
> Could this be the reason bacula just decided to use the local disk
> because it *could*, even though the mount clearly failed with an

If your share mounts on /mnt/bacula, and the share isn't mounted, bacula
will quite happily just write to the /mnt/bacula directory. To avoid
this problem I always back up to a subdirectory inside that share. Eg In
that case I would back up to /mnt/bacula/volumes/ or something like
that, although I wouldn't normally call my mount point bacula so it
would be more like /mnt/cifs/bacula where cifs is the mount point and
bacula is a directory under it. That way if the share isn't mounted, the
directory won't exist and bacula won't do something you aren't
expecting. I think this is advisable for CIFS and USB attached storage,
the latter is what I normally use.

I assume you also allow Bacula to create new volumes... that would
probably be a mitigating factor here too.


WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
Bacula-users mailing list