Hi Mehrdad,
Am 04.02.2025 um 11:03 schrieb Mehrdad Ravanbod:
Hi
I have come up against a seemingly difficult problem
Running Bacula 15.0.2 on a Redhat 9 clone, backing up windows
machines(via winows agents) to a network share(well, trying to), so I
want to back up from the windows machines via the FD and SD agents
directly to Big Share(which is on another server)
Why do this with an SD on each windows host? Sounds like an
unnecessaryily risky architecture, having many putentially exposed hosts
with access to your backup data. Ensuring access to backup volumes is
limited to as few systems, and as securely managed as possible, should
be a key consideration when designing a backup system.
The problem is it does not work, i have a FD and SD agent on the winows
machines, if i backup to a local folder it works(on the window machines
local disk), i.e Archive Device=<local folder> in device def i bacula-
sd.conf
But if i set Archive device=<net work share> or Archive device=<mapped
drive> it does not work, and i get
[SE0017]Unable to Stat device .... at z: : Err=No error
[SW0106]Device .... Requested by DIR could not be opened or does not exist
The network share needs to belong to the session you run the SD in. This
means a network share you see in the explorer is not enough.
You'll probably need to come up with your own wrapper around the SD
which mounts the network share prior to starting the SD accessing it.
See above why I think this is a bad idea, though.
What I have done:
mapped net workshare a drive, fail
Everything you do in a log-in session will not be accessible by a
service session.
used mklink /d to make a symlink to the newowrkshare, fail
tried even running the SD-service under domain admins (just in case it
is a case of permissions), fail
I am pretty sure this should be possible, right?? But can't find any
thing in the documentation. Anyone who has tried it and knows how to, or
has some advice???
Besides the security considerations, I wouldn't recommend running the SD
on Windows. At best, you'll see security and performance problems. At
worst, you find that the fact that's it not been very thoroughly tested
let potential data corruption slip through the dev team's testing nets.
And of course you'll find yourself limited to only support plain file
volumes, and have to manage many more firewall rules, permissions, and
possibly even accounts than necessary.
All that said -- what do you want to achieve by doing things this
particular way?
Cheers,
Arno
--
Arno Lehmann
IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
