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
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 toward what you want ...
On Thursday 01 September 2
> We want to backup all our clients to disk and then mirror
> these backups to tape. We want the ability to do quick
> restores from the disk (last
> 2-4 weeks depending on backup size) but also create a tape
> archive spanning several months if we need anything that is
> not on the disk-stora
14 matches
Mail list logo
