Hello, pon., 10 lut 2020 o 23:01 Dimitri Maziuk via Bacula-users < bacula-users@lists.sourceforge.net> napisał(a):
> On 2/10/20 4:12 AM, Radosław Korzeniewski wrote: > > > 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? > > How should I know why you need a "specail" SD instead of a "regular" one? > Because a community _always_ know better then developers. :) Just read some hot threads on this group. > > > This is a kind of help I want to get from community as you always > complain > > about decisions which developers take himself. > > I personally only care about failure of my HDD "magazine" being written > to. SD writing to two file descriptors instead of one is all *I* want. > > This is a small tip of the ideberg! and the devil is in the details - always! I.e. how you want a single SD disconnection and reconnection to be handled? Do you want to fail the whole job? or continue on remaining one? what about a disconnected SD and its partially written volume on reconnection? do you want SD reconnection in this case? do you want a single or multiple jobs (in case if simple job mirroring) stored in catalog db? do you want to fall back to other volume/job during restore errors? etc. etc. etc. all of these requirements you do not want to discuss are the important part of the functionality. I can implement a functionality which community reject. This is not what I want. > I don't even care for having the 2nd copy in the catalog: I just want > the same exact volume file on two physical drives. Then use low-level block replication (storage array or storage cluster - sds or even os-level like drbd). It is fast and proven to be extremely reliable as Enterprise class solutions. But we are discussing about application-level replication or RAIT like solution. This is a very different story. > Somebody else may want the copy to go to "the cloud" instead, that may > or may not require a different approach. > Sure, so I want to discuss that will be the better or the best approach in this case. best regards -- Radosław Korzeniewski rados...@korzeniewski.net
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
