> 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.
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-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
