Re: [Bacula-devel] Migration

[Kern S. <ke...@si...>]

On Tuesday 22 August 2006 19:37, David Boyes wrote:
> > Yes, I have not forgotten about Consolidation (or if I remember right s=
ome
> > users call them Virtual full backups).  Adding Consolidation is much mo=
re
> > straight forward than Copy, but does require code to generate a correct
> > bootstrap file ...
>=20
> Consolidation is just volume-to-volume migration.=20
>=20
> > > Possibly na=EFve question: does the director or the SD write the reco=
rd
> > that
> > indicates where the file is on the tape?
> >=20
> > The SD sends the info to the DIR, which creates the records.  However, =
for
> > the
> > DIR it is a transparent operation (i.e. the DIR just passes the data to
> > the
> > database).
>=20
> Hmm. That removes the concurrency locking problem on the file table very=
=20
neatly.=20
>=20
> >=20
> > Well, my head is still spinning from Migration and worrying about what
> > kinds
> > of problems I still must resolve, then there is Consolidation and Copy,=
 so
> > I
> > cannot at the moment even begin to think about muxing anything :-)
>=20
> Gotcha.=20
> =20
> > The only comment I *can* make is that I don't see any need to have any
> > special
> > mux front-end as that would just complicate things.  If you are talking
> > about
> > writing two output streams, then what we need is the DIR to inform the =
SD
> > to
> > have two write drives open, then when the info comes from the FD to the
> > SD,
> > it will be sent to both (or more) drives.  Since the SD already knows h=
ow
> > to
> > handle all the appropriate records, it is just a "trivial" matter of the
> > symantics of this in the DIR and making some small tweaks to the SD to
> > open
> > two drives (the base mechanism exists).
>=20
> The only problem I can see with that approach is that it limits you to=20
generating the SD copies at only one location. The mux approach would also=
=20
work in that scenario, but also permit the additional SDs to be physically=
=20
located elsewhere (ie, offsite, but with network or VPN connectivity to the=
=20
mux) so that the copies could be automatically be generated in multiple=20
physical locations.=20

I don't see that generating SD copies at only one location is a limitation,=
=20
rather it is a first step in getting something more general.=20

No sort of mux software between the FD and the SD (or SDs) is going to solv=
e=20
the problem of generating multiple copies on multiple SDs.  That project=20
needs very careful coordination between the Director, the FD, and all the S=
Ds=20
involved.  Each SD must *before* doing any copy have a valid job started by=
=20
the Director, otherwise, the SD has no way to interface to the catalog.

>=20
> It would also be fairly simple to only invoke the mux when multiple copie=
s=20
are needed. I think the director hands the FD the address of the selected S=
D,=20
right? If so, and the primary storage pool specified in the job has no=20
copypool defined, you hand it the direct address of the SD and all happens =
as=20
it does today. If the primary pool in the job had copypool(s) defined, do t=
he=20
mux setup, and then hand the FD the address of the mux.=20
>=20
> > The big problem is later managing multiple copies for restores.  IMO, t=
his
> > is
> > non-trivial.
>=20
> Very likely. Conceptually, it's easy. Implementing it will probably not b=
e.=20
>=20
>=20