This is equivalent to what we're doing now, but we're sort of one step up in
the hierarchy - backing up one tablespace at a time.
You don't say whether you mean to back up each table to tape as it's produced,
or back them all up at the end when they've all been copied.
Either way, there's problems.
The second option, copying/dumping them one at a time and then backing them all
up to tape at the end, is what we're doing now, and it works... for now. The
problem is, it currently takes about 12 hours or so to do this, with 700GB of
data. We're expecting the database to grow to 5-7 terabytes, which will
(assuming linear scaling) take about 120 hours to back up, which isn't
particularly suitable for a daily backup :) Not to mention running out of
intermediate disk space to keep it on for the duration of the operation.
The first option, back up each table copy/export/dump as it's produced, has two
problems. Firstly, it's effectively the same as the other option with respect
to amount of data shuffled around and hence how long it'll take. (Unless we can
be doing the tape backup of one file while we're doing the copy/export/dump of
the next one, which would speed things up mightily.) The main problem with this
is I have no idea how to do this with Bacula, without creating a separate
Bacula job for every table(space), which as I think I mentioned in my original
email opens up a whole lot of manual re-configuration on a frequent basis, and
hence the likelihood of missing bits and thus invalidating the entire backup...
and not noticing until it's too late.
I know that Legato Networker plus RMAN allows you to give the database server
the tape drive and tell RMAN to do the backup, with Legato still managing the
tape changer and looking after the volumes (retention periods etc). I haven't
found anything that'll tell me how to do this with Bacula, with or without
RMAN. If I could find something that told me how, from a script, to tell Bacula
to back up a given file/directory, now, to whatever tape is appropriate (find
one and mount it if required), then I could fairly easily script up an
iterative loop to go through all the tablespaces and bacula them straight
across the network to tape. Basically integrate Bacula into the script I
already have so it baculas the data to tape instead of copying it to disk. Even
better, if I could get my head round how to configure Bacula to cope with a
tape drive on one server being fed by an autochanger on a different machine, I
could even eliminate the cross-network bit.
Cheers,
DJ
-----Original Message-----
From: Hemant Shah [mailto:hjrrs AT yahoo DOT com]
Sent: Wednesday, 26 November 2008 10:44
To: James Cort; David Jurke
Cc: bacula-users AT lists.sourceforge DOT net
Subject: Re: [Bacula-users] How to set up large database backup
--- On Tue, 11/25/08, David Jurke <David.Jurke AT tnzi DOT com> wrote:
> From: David Jurke <David.Jurke AT tnzi DOT com>
> Subject: Re: [Bacula-users] How to set up large database backup
> To: "James Cort" <james.cort AT u4eatech DOT com>
> Cc: "bacula-users AT lists.sourceforge DOT net" <bacula-users AT
> lists.sourceforge DOT net>
> Date: Tuesday, November 25, 2008, 12:34 PM
> Thanks James,
>
> Sorry, missed that bit... Oracle on Linux. The database is,
> as you say, for the business, hence the need to back it up!
>
How about exporting/dumping one table at a time and then backing up the
exported data using bacula.
> And sadly no, our SAN doesn't support snapshots, or for
> sure I'd have been doing that! Likewise I don't have
> the option of breaking RAID mirrors and doing it that way.
>
>
> Cheers,
>
> David.
>
> -----Original Message-----
> From: James Cort [mailto:james.cort AT u4eatech DOT com]
> Sent: Wednesday, 26 November 2008 00:02
> To: David Jurke
> Cc: bacula-users AT lists.sourceforge DOT net
> Subject: Re: [Bacula-users] How to set up large database
> backup
>
> David Jurke wrote:
> >
> > The method we're using for now is to back up the
> database by copying it
> > to disk on the backup server (via NFS), and then back
> that up to tape.
> > Trouble is, this is handling the data twice, and is
> currently taking
> > well over twelve hours all up, which given the
> expected growth is going
> > to become untenable fairly soon, so any suggestions
> gratefully received!
> > Not to mention we're going to run out of disk
> space!!
>
> You don't mention what OS or DBMS the database is,
> given the context I'm
> assuming it's for some other business process than
> Bacula.
>
> Does the SAN support snapshots? You could always take a
> snapshot, back
> it up and then remove the snapshot afterwards. There may
> need to be
> some scripting to make sure the database is in a consistent
> state before
> you do this, but it'd be a lot quicker than copying the
> data.
>
> --
> James Cort
>
> IT Manager
> U4EA Technologies Ltd.
>
> --
> U4EA Technologies
> http://www.u4eatech.com
>
>
>
>
> -------------------------------------------------------------------------
> 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
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Bacula-users mailing list
> Bacula-users AT lists.sourceforge DOT net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
Hemant Shah
E-mail: hjrrs AT yahoo DOT com
-------------------------------------------------------------------------
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
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
