On 2/10/2020 5:12 AM, Radosław Korzeniewski wrote:
Hello,
pt., 31 sty 2020 o 16:27 dmaziuk via Bacula-users
<bacula-users@lists.sourceforge.net
<mailto:bacula-users@lists.sourceforge.net>> napisał(a):
...
the 2nd SD can write to "the cloud", it can be on the
off-site box, etc. Whereas amanda-style RAIT device only protects
against single disk/tape failure.
So, why not to design a special kind of SD which will get data from FD
and then save it on different backend SD synchronously defining full
and flexible RAIT or EC solution?
This is a kind of help I want to get from community as you always
complain about decisions which developers take himself.
I, for one, would prefer it be implemented in the SD and not in the
client. This allows a single interface for the client, while allowing
the SD to communicate with SDs on other networks that are perhaps not
accessible to the client. Also, this allows adding multiple device
capability without having to update all clients.
What about a SD writing to multiple local 'Device' objects? And segueing
into a related subject, why is a job locked into a particular Device at
job startup? Rather than a one-time allocation of device and then one or
more subsequent allocations of volume(s) as separate operations, why not
allocate device and volume together as a pair in a single atomic
operation? This would allow a job to potentially change devices when a
different volume was needed and would be beneficial for autochangers
that have more than one drive, including virtual disk autochangers.
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
