You could set up an S3 compatible server on your destination server, then instead of copying bacula volume files to the remote SD via NFS you could use a copy job that targets the S3 server. The traditional advice was to use minio for this, but the company that maintains minio appears to be stripping features out to drive traffic to their closed source product offerings. So I recommend looking into another s3 server project.
Overall, once you have a working s3 server on your hardware, you could easily set up a cloud copy job. You would want bacula 15.x for this. I would also recommend setting firewall rules to only allow connections to your s3 server from certain trusted endpoints in your infrastructure. I have discussed this subject somewhat extensively on the list before. Please search for an email from me to the list, containing the word 'minio'. My email regarding Jan's problem contains some information that may be useful to you (and some information that is not relevant to your situation). Robert Gerber 402-237-8692 [email protected] On Wed, Sep 16, 2026, 1:48 AM Stefan G. Weichinger via Bacula-users < [email protected]> wrote: > Am 15.09.26 um 18:50 schrieb Arno Lehmann via Bacula-users: > > Hi Stefan, > > > > Am 15.09.2026 um 17:26 schrieb Stefan G. Weichinger via Bacula-users: > >> > >> I am perfectly aware that mounting NFS via Wireguard VPN is out of > >> scope here! > > > > Probably a topic nobody wants to have on scope :-) > > exactly ;-) > > >> But I'd like to ask how to configure the Storage device in Bacula(ris) > >> to at least get rid of errors there, maybe. > >> > >> As far as I understand Bacula-SD is able to trigger the mounting of a > >> filesystem before accessing the storage device. > > > > Personally, i'd try to avoid that. > > > > Have you tried automounting? > > Not in this case, but I know what you suggest. > > I have to roll back a bit: the mounting isn't the problem here, as you > also understand. > > The share is mounted fine by systemd even with a "legacy fstab entry". > > The issue is the connection, not the mounting itself. > > Also, I'd probably run a dedicated SD process for such unreliable > > mounts, so it's less disruptive if there's a long timeout (NFS should be > > "hard" mounted IMO) which could block the SD thread and in consequence > > cause issues for other devices, too. > > Yep. I have it hard-mounted and played with some options, but it just > doesn't behave yet. > >> So I assume this relates to the "user" option of nfs filesystems in > >> fstab ? > > > > Yes. Combined with extra configuration which I would try to avoid. > > Understood, I fully agree. > > Explicitly setting rsize and wsize is most of the time counterproductive > > IMO. > > OK > >> Maybe nfs isn't the right protocol here. > > > > I suppose so. Something inherently resilient against timeouts and > > unreliable connections would be more useful. File systems usually are > > *not* designed for that use case. > > > > You could try using an S3 endpoint, but Bacula's native S3 object > > storage support will still require considerable local storage as it > > decouples backup and final object upload. > > hmm. > > The goal is: "copy Bacula volumes from the NFS-mounted storage in the > server site to the NAS in the office (mounted *somehow*)" > > Maybe I should try to let the NASes sync that share with NAS-tools ... > and don't use Bacula-SD for the 2nd NAS. It just would be comfortable to > have everything in Bacularis for overview and handling. > > The usual protocols are CIFS and NFS on these devices ... I wonder if I > could mount NAS2 via iscsi instead. More hours of tests ahead, it seems. > > > Hopefully this gives you ideas at least -- a simple, reliable solution > > is probably a bit unrealistic for your scenario :-) > Thanks for your suggestions! "Simple and reliable" is a goal I rarely > reach ;-) > > > > _______________________________________________ > Bacula-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/bacula-users >
_______________________________________________ Bacula-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-users
