>
> Robert LeBlanc wrote, sometime around 11/10/07 12:03:
> > We put MS SQL in full recovery mode, then have a maintenance
schedule in
> MS
> > SQL that does a full back-up. We exclude the actual data files and
> include
> > the log files (full and transaction). We have the schedule run about
15
> min
> > before bacula runs on the client. I think the RunBefore Client would
be
> a
> > better option though.
>
> I currently have a maintenance plan which does a consistency check and
> then database backup followed by log backup (the latter is needed if
you
> don't want your log files to grow to infinite size when a database is
in
> 'Full' recovery mode).
>
> This currently runs asynchronously w.r.t. bacula, so I just make sure
> that I schedule the bacula job to run at a time by which the database
> server will have dumped its backups.
>
> I also have a client run before job script (shell script executed with
> cygwin), which prunes backup dump files older than a week, and gzips
the
> remainder (SQL Server backup files gzip rather well, I find). I think
I
> trust gzip to do a better job than the tape drive's hardware
compression.
>
> If you look at the maintenance plan, all it does is call a stored
> procedure with some arguments. It should be trivial to call this from
> the client run before job too, making the whole process synchronous.
>
> I also saw someone having some success running backups over named
pipes
> and streaming them directly to tape, avoiding the middle step of
dumping
> databases to files before backing up. I like having an online copy of
> the database backups though, as it makes restoring in the common case
> ("something went wrong and we need last night's backup now!") much
> easier. Backups are handy for recreating test copies of databases too.
>
I wrote an agent for MSSQL which worked quite well, although it's in a
non-working state at the moment as I started working on the Exchange
agent which involved a rewrite of the base class. The Exchange agent has
been running in production use for over a month now, so I think it's
pretty stable (see archive for more details). I hope to get back to the
SQL agent for bacula in the next few months, but work suddenly got
really busy :)
Basically it's a program that pretends to be a Bacula FD, and creates a
filesystem namespace out of MSSQL elements, eg
/<instance>/<database name>/database
/<instance>/<database name>/logs
... filegroups
... files
Once backed up, you could also just restore the backup using the normal
bacula fd, which would give you a file you could then restore with
MSSQL, eg "RESTORE DATABASE xyzzy FROM DISK='C:\tmp\whatever'".
One of the things that has been added to Bacula since I first wrote the
agent is much more flexible restore redirection, so I should now be able
to get the 'restore to another database' option working in a sensible
way. Not sure about 'point in time' restores though... not sure that
Bacula has the flexibility to allow this... I think it would need some
knowledge of MSSQL. Probably best just to restore everything to files
and do it manually. I'm sure someone will correct me if I'm wrong though
:)
But for now, use VSS (which apparently has been documented to work), or
do what everyone else does and just use MSSQL to back up to a file which
in turn gets backed up by bacula.
James
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
