On Tue, Sep 21, 2010 at 08:19:21AM +1000, James Harper wrote:
> > Hello,
> >
> > I am testing backups of an Exchange 2003 server, with the plugin. I
> have a
> > schedule of incrementals with occasional virtualfulls.
> >
> > The idea being that, after the first real full, doing a full backup is
> no
> > longer required (unless I restore the whole Exchange database, because
> > Exchange then demands a full backup).
>
> Or if you apply a microsoft update / hotfix. That's caught me out a few
> times in Backup Exec which crashes the exchange services when this
> happens.
>
> > But, I have realised that the Exchange logs are never 'truncated'
> because
> > there is never a real full backup.
> > Looking at the plugin code and the documentation, the logs get
> 'truncated' on
> > a
> > real full unless you give an option to the plugin for it not to
> happen.
>
> And a differential I think.
>
> >
> > As I understand it, this means that the logs will just build up and up
> on the
> > Exchange server.
> >
> > Is there a way of getting the Exchange logs to 'truncate' when doing a
> > virtualfull?
> > Or does somebody have another suggestion?
> >
>
> If you know a bit of C, you could do the following:
>
> Add a "alwaystrunc_option" member just after notrunconfull_option to
> exchange_fd_context_t in exchange-fd.h
>
> Init it to false in newPlugin
>
> Add something like:
> if (context->alwaystrunc_option) {
> context->truncate_logs = true;
> }
> To exchange-fd.c after switch(context->job_level) in exchange-fd.c after
> case bEventStartBackupJob: to override the context->truncate_logs flag
> despite whatever has been set prior.
>
> Add something like:
> else if (stricmp(option, "alwaystrunc") == 0){
> context->alwaystrunc_option = true;
> }
> In bEventBackupCommand for the option parsing.
>
> Once you do that, you should be able to append :alwaystrunc to the
> backup command to tell it to always truncate the logs.
>
> The reason for this complexity is that Exchange maintains its own
> 'backup state'. It knows when the last full backup was done and
> determines what needs to be backed up itself, while Bacula expects to
> set those parameters itself too (via the 'since' parameter). By keeping
> the logs around on incremental we can still do a differential too
> because the logs aren't thrown away.
>
> The alwaystrunc options should probably be split out into 'always trunc
> on incremental' and 'always trunc on differential' flags for maximum
> flexibility but the above should be a good starting point.
>
> If the above suggestions are not something you feel able to do I might
> be able to put a patch together, but not this week.
OK, that sounds easy enough.
Attached is my patch to bacula-5.0.3 (completely untested at the moment).
I've made two new options:
truncondiff
trunconincr
I will report on whether it works in a while.
------------------------------------------------------------------------------
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-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
