On 5/9/2018 5:37 PM, Chris Wilkinson wrote:
I am experimenting with using Bacula to back up several (m) cifs
shares on one Nas box to (n) sub-directories of a cifs share on
another. Neither Nas is able to run a client directly as they are
commercial locked down boxes.
My configuration is a Debian server and two non-identical Nas boxes.
They are on the same subnet.
My first try at this mounts the shares of each Nas on Debian. I define
devices pointing to the backup Nas mounts (bacula-sd.conf).
Device { #1
...
Archive Device = /mnt/backup_nas/dir_1
...
}
Device { #n
...
Archive Device = /mnt/backup_nas/dir_n
...
}
I define n Storage {...} sections (bacula-dir.conf) pointing to these
devices.
I define m clients pointing (bacula-dir.conf) to the various shares on
the data Nas. I am not sure if I need to define m FileDaemon {...}
(bacula-fd.conf) sections to make the link to the clients.
You do not need m FileDaemons, but you do need to mount the data_nas
shares. The Debian server, in addition to mounting the backup_nas shares
that it will write to, will also need to mount the m data_nas shares
that it will read from. Then you can either define m Job sections in
bacula-dir.conf, where each job specifies one of the data_nas
mountpoints, or alternatively, in the Job section that backs up the
Debian server itself, add a File= line for each of the m data_nas
mountpoints. Bacula will not by default descend into other mounted
filesystems. All of the filesystems to be backed up must be specified by
a File= line in the Job section that specifies its mountpoint.
This is probably not a scenario that Bacula was designed for. Is this
a viable approach?
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
