Hi Don,
First off please ensure that you include bacula-users in your follow
ups.
On Wed, 2007-01-03 at 18:05 -0700, MacArthur, Don wrote:
> Thanks Richard! The offsite thing is exactly what I'm doing. I write
> to tape first to go offsite, and then write to file for
> speed/convenience when restoring files.
>
> I would prefer to copy the first backups instead of running a second
> set
> to spare the servers the second trip. Plus, since both backups are
> identical I won't have to explain why one backup has x number of files
> and the other has y number of files.
>
> Re-reading the document with your info in mind, it sounds like the
> catalog records are deleted - or, are they? Is a flag set? A flag I
> can change with a "run after" query...?
>
I cannot claim to be an expert on this. Kern wrote most (all!) of the
migration code I just tested it quite a bit. However I'm happy to try to
answer especially since Kern deserves a rest after getting 2.0.0
released.
Your question prompted me to take a look in src/dird/migration.c it is
something that I've been meaning to work out for quite some time. Anyhow
at the end of the job it calls
migration_cleanup(jcr, jcr->JobStatus);
if (mig_jcr) {
UAContext *ua = new_ua_context(jcr);
purge_job_records_from_catalog(ua, jcr->previous_jr.JobId);
free_ua_context(ua);
}
migration_cleanup updates the Job table entry for the newly migrated job
with the StartTime, EndTime and JobTDate of the previous job (to ensure
that pruning is consistent with the previous job). The previous job is
marked with status 'M' to say that it has been migrated. Media records
and volume names are updated for the new job. Then the job termination
(status) message is produced.
I think that purge_job_records_from_catalog is the thing that does away
with the detailed data for the previous job. It removes the File
records, JobMedia and Log records and markes the job as having
PurgedFiles=1.
Once the migration has completed you would need to do something like a
bscan on the old volumes (assuming that they had not been recycled) to
use that data. It shouldn't be too difficult to make sure that your
off-site tapes do not get recycled automatically. The only problem is
that you would need to keep a manual record of what jobs were on which
tape etc.
This last bit is obviously the bit that will change when "Copy" job is
implemented. However as I remember the main issues with Copy are more
how does the director know when to use the original and/or copy of the
volume when doing restores.
> I looked at the (postgres) files and didn't see anything obvious in
> the
> job or media files. So, how does it mark them for pruning/purging?
>
As shown above it just purges things there and then.
> Again, thanks much for the info.
No problem.
Hope this helps.
Richard
>
> On Wed, 2007-01-03 at 22:05 +0000, Richard Mortimer wrote:
> > On Wed, 2007-01-03 at 14:43 -0700, Don MacArthur wrote:
> > > I'm preparing to upgrade from 1.38.7. My current nightly process
> looks
> > > like this:
> > > 1. Backup to tape.
> > > 2. Backup to file.
> > >
> > > In looking at the current documentation on bacula.org, the
> migration job
> > > info says a migration *moves* the data and pointer in the catalog
> to new
> > > volumes.
> > >
> > > Somewhere else (I think on the list), I saw a note from Kern with
> the
> > > text "Migration/copy".
> > >
> > > My question is, can I use a migration job to *copy* my backup jobs
> to
> > > new volumes - as opposed to *moving* them? If so, can you point
> me to
> > > the documentation/posting?
> > >
> > Migration copies the data from one volume to another (note it must a
> > volume on a different storage device). After the copy is complete it
> > marks the data on the old volume as being obsolete (and hence
> subject to
> > volume purging etc). The key is that if you try to do a restore
> after
> > the migrate it will take the data from the new volume and not the
> old.
> >
> > Copy is a future extension (not currently scheduled) that is more
> like
> > an offsite copy. The idea there is that the restore would come from
> the
> > original volume but if need be you could get it from the offsite
> volume.
> >
> > So to answer your question you can use migration to copy the data
> but
> > the bacula catalog will only try to use new copy of the data at a
> later
> > date. The original data will still exist until a volume gets reused.
> >
> > Regards
> >
> > Richard
> >
> > > I have searched the list, so I apologize if I missed it.
> > >
> > > Many thanks in advance.
> > >
> > >
> -------------------------------------------------------------------------
> > > Take Surveys. Earn Cash. Influence the Future of IT
> > > Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> > > opinions on IT & business topics through brief surveys - and earn
> cash
> > >
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > _______________________________________________
> > > Bacula-users mailing list
> > > Bacula-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/bacula-users
>
>
--
Richard Mortimer <[EMAIL PROTECTED]>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
