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:[EMAIL PROTECTED] Sent: Wednesday, 26 November 2008 10:44 To: James Cort; David Jurke Cc: bacula-users@lists.sourceforge.net Subject: Re: [Bacula-users] How to set up large database backup --- On Tue, 11/25/08, David Jurke <[EMAIL PROTECTED]> wrote: > From: David Jurke <[EMAIL PROTECTED]> > Subject: Re: [Bacula-users] How to set up large database backup > To: "James Cort" <[EMAIL PROTECTED]> > Cc: "bacula-users@lists.sourceforge.net" <bacula-users@lists.sourceforge.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:[EMAIL PROTECTED] > Sent: Wednesday, 26 November 2008 00:02 > To: David Jurke > Cc: bacula-users@lists.sourceforge.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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users Hemant Shah E-mail: [EMAIL PROTECTED] ------------------------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users