Kern Sibbald wrote:
On Wednesday 26 October 2005 20:31, Attila Fülöp wrote:
Kern Sibbald wrote:
For example, with a trivial amount of work, I could modify Bacula to
handle an autochanger with several Media Types, but each drive would have
only one Media Type that it would read/write.
This w
> > Hmm. I don't think that would pass our auditors. If there's a
> > significant chance that the copies are not identical (and it sounds
> > like this approach pretty much guarantees that the copies
> will not be
> > identical), I don't think it would be sufficient or useful for this
> > purp
On Wednesday 26 October 2005 20:31, Attila Fülöp wrote:
> Kern Sibbald wrote:
> > For example, with a trivial amount of work, I could modify Bacula to
> > handle an autochanger with several Media Types, but each drive would have
> > only one Media Type that it would read/write.
>
> This would be gr
Kern Sibbald wrote:
For example, with a trivial amount of work, I could modify Bacula to handle an
autochanger with several Media Types, but each drive would have only one
Media Type that it would read/write.
This would be great anyhow, since it would allow me to connect
an additional (DDS) d
On Wednesday 26 October 2005 19:01, David Boyes wrote:
> > > Hmm. I don't think that would pass our auditors. If there's a
> > > significant chance that the copies are not identical (and it sounds
> > > like this approach pretty much guarantees that the copies
> >
> > will not be
> >
> > > identica
On Wednesday 05 October 2005 17:59, David Boyes wrote:
> > > Hmm. Does the second job transfer the data from the FD
> >
> > again? If so,
> >
> > > then that doesn't (IMHO) quite do what I want to do here. I really
> > > want to transfer the data only once (the only guarantee we have of
> > > getti
I scoped the problem as two major projects:
> >
> > 1) implementation of "copy pools" -- where files written to a pool
> > were automatically also written to up to 3 additional pools
> using the
> > same volume selection criteria as exist now (essentially
> getting the
> > SD to act as a FD
> > Hmm. Does the second job transfer the data from the FD
> again? If so,
> > then that doesn't (IMHO) quite do what I want to do here. I really
> > want to transfer the data only once (the only guarantee we have of
> > getting the same data on all the copies) and create the
> replicas on t
On Tuesday 04 October 2005 15:15, David Boyes wrote:
> I scoped the problem as two major projects:
> > > 1) implementation of "copy pools" -- where files written to a pool
> > > were automatically also written to up to 3 additional pools
> >
> > using the
> >
> > > same volume selection criteria a
I scoped the problem as two major projects:
1) implementation of "copy pools" -- where files written to a pool were
automatically also written to up to 3 additional pools using the same volume
selection criteria as exist now (essentially getting the SD to act as a FD
to more than one FDs to ensu
Hello David,
On Monday 03 October 2005 21:20, David Boyes wrote:
> I scoped the problem as two major projects:
>
> 1) implementation of "copy pools" -- where files written to a pool were
> automatically also written to up to 3 additional pools using the same
> volume selection criteria as exist no
Hi,
On 03.10.2005 20:06, Kern Sibbald wrote:
Hello,
Did you ever get an answer to this? If not it is a real pity. In any case,
beginning in November, I will be making a new Wish List, and this item will
probably be on in, if not, please submit it. Then maybe we can make some
progress tow
12 matches
Mail list logo
