Thanks for the responses, Mike and Arno.

It went easily and trouble-free enough, given the complexity and 
inter-relation between the config files that life on multiple hosts.

On Monday 14 May 2007 4:28:23 pm Arno Lehmann wrote:
> > I've been using mySQL.  I know how to get a dump of the database out, and
> > how to read that database back in.  I intend to use that to "migrate" the
> > database to the mySQL server on the new director.  I don't think that
> > will cause any problems.  I'm open to being corrected.
>
> I don't think you'll encounter problems there.

Not a single problem.

> > With the director moving off of the original sun machine, I'm going to
> > rename the sd and fd on that machine.  If I have to do restores, I know
> > that I'll have to change the restore-from devices and such.  Currently
> > their named bacula-sd and bacula-fd.  I intend to change them to
> > [hostname]-fd/sd.  Are there any snafus I might encounter there?
>
> Just keep in mind that you'll have to start with a full backup again to
> allow simple full restores. I don't know if Bacula enforces that, but I
> suspect it will, because the FD name and FileSet ID combination is
> (IIRC) how Bacla identifies identical jobs.

Bacula did not enforce a full backup on the renamed SD or FD, which I found 
interesting.  I know it triggers an upgrade to "Full" if the fileset changes.  
I'm curious why it didn't with the new SD/FD names.  I did just re-use the 
same passwords and of course the hostnames stayed the same.

As I mentioned, I wanted to rename the FD and SD that I'd been using on the 
old director.  I have tested running a couple restores using volumes that 
were written before the FD and SD changed names and bacula handled the new 
names of both the SD and FD gracefully, so, my concerns, and the concerns of 
Mr. Lewinger can be laid to rest.

Note that I did not change the names of the devices on the SD, just the name 
in the Storage definition in the director and in the bacula-sd.conf, as well 
as updating it in the appropriate places for pool/job/schedule definition.  
Okay, so I guess I changed it in a lot of places.  

> > Anything else?
>
> I don't think so... in any case, keep a copy of the catalog before
> migration, and only decomssion the old DIR after you ran all backups
> successfully with the new one.

Of course!  If at all possible, and unless I screw up, I always try to keep 
the "go back to what was working" option available.

I wish that practice was born out of foresight and intelligence instead of 
painful experience. *grin*

-- 
-- Flak Magnet (Tim)
www.flakmagnet.com

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to