On Saturday 11 September 2010 01:43:49 James Harper wrote:
> > On Friday 10 September 2010 03:22:22 James Harper wrote:
> > > What is JT_ARCHIVE used for? I put virtual full backups on tape and
> > > don't want them selected for a subsequent virtual full backup so I
>
> need
>
> > > to tinker with the job record so that the db_accurate_get_jobids
>
> routine
>
> > > that is used to find the source jobs for a virtual full backup
>
> doesn't
>
> > > see them. The criteria for the job selection of the FULL job is:
> > >
> > > Level='F' (Full backup)
> > > JobStatus IN ('T','W') (Terminated normally or with warnings)
> > > Type='B' (Backup)
> > > FileSet.FileSet=(SELECT FileSet FROM FileSet WHERE FileSetId = %s)
>
> (Same
>
> > > fileset)
> > >
> > > So my options are to modify one of those fields in the catalog,
> > > hopefully in such a way that nothing else breaks (including being
>
> able
>
> > > to restore from tape, even if I have to select the job manually).
> > > Setting the job type to JT_ARCHIVE seems like it might work as long
>
> as
>
> > > that doesn't stop Bacula purging out the job records when the media
>
> is
>
> > > recycled. Another option is to set the Type to JT_JOB_COPY, or to
>
> create
>
> > > an identical fileset but with a different name and set the FileSetId
>
> to
>
> > > that new fileset (which relies on me keeping the filesets in
>
> sync...)
>
> > > JT_ARCHIVE is my first choice though, anyone see any problems with
>
> that?
>
> > JT_ARCHIVE is meant to be an archive job -- the exact definition of an
>
> archive
>
> > job is not yet determined (whether or not it removes the original
>
> file), but
>
> > it is intended to be something where the job records will not be
>
> pruned.
>
> > The current implementation is far less than minimal, so if you start
>
> using
>
> > JT_ARCHIVE, you are likely to run into problems with pruning and
>
> possible
>
> > other things -- e.g. your job records may be pruned early or not
>
> pruned.
>
> > This is simply because it is not yet implemented. In addition, the
>
> behavior
>
> > of JT_ARCHIVE, not being defined, and not being implemented, it will
>
> surely
>
> > change ...
>
> Any suggestions then as to how I can tell Bacula that a given job is not
> available as the 'source' for a VirtualFull? The target of the
> VirtualFull job is a tape and so will only be used for restore in the
> event of a complete disaster.
We don't currently have anything that does exactly what you are asking for.
Copy jobs do behave in that manner -- that is only the original Backup will
be used rather than the Copy. However, it is assumed that there is always a
Backup and a Copy -- this may be in our conceptial design rather than what
the code actually implements though. So, you might try marking it as a Copy.
However, I recommend some testing. The problem is if the job is needed for
restore (i.e. would normally be used), and it is not available, it seems to
me that something is going to go wrong.
Kern
> All normal restores will be done from
> disk, so as long as I have an intact copy of the catalog on the tape for
> in the event of a disaster, I could just purge the jobs once the catalog
> has been saved to tape. That's harder than just setting a flag on each
> job as it gets written out to tape, but the more I think about it the
> more it sounds like a better option...
>
> James
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel
