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
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
purpose. It
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
identical), I don't think
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)
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 great
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
getting the same data
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
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 the server
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 as exist now
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 now
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
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
12 matches
Mail list logo
