[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] Backing up MS Exchange
On Wednesday 10 September 2008 12:15:24 James Harper wrote:
> > Yes, I haven't figured out exactly how we will handle this. From what
> > read
> > on the web, if you are doing a VSS backup (Bacula is backing up the
> > system), Exchange is sort of blocked or locked, so doing the normal
> > calls
> > to Exchange either fail or won't work correctly. As a consequence, we
> > need
> > to ensure that VSS is not enabled at the same time that the plugin is
> > running.
> I'm not completely sure, but I think that the locking only occurs once a
> VSS backup of Exchange is started. Provided we exclude the Exchange
> database and log files from the VSS part of the backup there shouldn't
> be a problem. We need to back up the folders containing the Exchange
> data, just not the data itself though, otherwise the restore breaks if
> you are doing a full system restore (you can just create the folders
> yourself of course, if they don't already exist because you omitted them
> from the restore).
Yes, locking occurse only once a VSS backup of Exchange is started. However,
it works by us saying we want to backup drive C, and/or D, ... then all the
the VSS aware programs are called by the OS to put them in "backup" mode, and
so Exchange will be called and it will flush everything to disk and continue
doing disk writes until the backup operation is terminated by Bacula. This
means that Bacula must start VSS, do a backup, stop VSS then call the plugin
to do the Exchange backup.
> One other thing worth mentioning, if you are doing a baremetal restore,
> you need to restore the Exchange databases after you have restored your
> system and rebooted anyway, as the API requires that Exchange itself be
Yes, that is another issue. At worst, if someone does a bare metal restore
and the plugin tries to restore Exchange and Exchange is not running, it will
fail, and the user will then need finish the restore, start Exchange and run
a restore of Exchange -- all this seems to imply that it is probably better
to do Bacula plugin based backups in a separate job from the normal backup.
> So maybe the documented procedure should be to create a second
> fileset and restore it once the system is running? Otherwise excluding
> specific files from the restore would be a manual step.
Yes, that would work, or as I note, a separate job -- much like I currently
run my Bacula catalog backup as a separate job.
> In many ways I like my approach of a completely separate agent, but I
> understand why that isn't really a workable long term solution, unless
> we turn the problem on its head and make the bacula api something that
> get's imported into an agent as a separate dll rather than the other way
I am not sure why a completely separate agent gives any advantage over the
current plugin scheme. The plugin really has quite a lot of control. When
we get into this some more, please let me know when you find explicit
examples of why the separate FD worked better because I hope that we can make
sure that is not the case. In any case, the current plugin method seems to
be what virtually all the commercial vendors do with their "modules"
or "agents" so I don't think there is anything flawed about the basic plugin
idea -- the details of the plugins are another issue. I am still not at all
happy about the way it passes variables back and forth (i.e. the plugin can
get and set a good number of Bacula variables -- e.g. it can request the
level, ...). I'll probably add a new variable so the plugin can find out if
VSS is running.
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Bacula-devel mailing list
This mailing list archive is a service of Copilot Consulting.