Sorry I didn't make that clear, it's any directory you want. On a Windows TSM server, I've even sent the DB backup to a network shared disk that is physically on another machine (that involves some Windows account/permissions manipulation though).
-----Original Message----- From: Bill Wheeler [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 10, 2002 4:50 PM To: [EMAIL PROTECTED] Subject: Re: TSM DBBackup Can you specify any directory that you want to or is it specific to the /var/adsmpool directory? Bill Wheeler PDM Administrator -----Original Message----- From: Prather, Wanda [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 10, 2002 4:43 PM To: [EMAIL PROTECTED] Subject: Re: TSM DBBackup You have to start out by creating a DEVCLASS with devtype=file. That specifies the directory you want the file sent to. Here's an example: DEFINE DEVCLASS dbbkuptodisk DEVTYPE=FILE FORMAT=DRIVE MAXCAPACITY=204800K MOUNTLIMIT=1 DIRECTORY=/var/adsmpool SHARED=NO "dbbkuptodisk" is a made up name, use anything you like. MAXCAPACITY should be large enough to hold one DBBACKUP (although the DB backup will work OK if TSM has to break it into pieces). Then when you do your DB backup, it should look like this: backup db type=full devclass=dbbkuptodisk scratch=yes TSM will create, on the fly, a new file in the /var/adsmpool directory to contain the db backup. If the db backup is larger than maxcapacity, TSM will create a more file and the db backup will span the two files. You can find out what TSM calls the file by looking in the activity log or in the volumehistory file. (Or just looking in the directory....) The older db backups go away when you run DELETE VOLHISTORY (same as if your DB backups were going to tape). -----Original Message----- From: Bill Wheeler [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 10, 2002 4:09 PM To: [EMAIL PROTECTED] Subject: Re: TSM DBBackup How do you define where the flat file goes while the DBBackup is running? Bill Wheeler PDM Administrator -----Original Message----- From: Prather, Wanda [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 10, 2002 3:27 PM To: [EMAIL PROTECTED] Subject: Re: TSM DBBackup Yes, TSM DB restore is the same no matter if you are restoring from disk or tape. If you rely on TSM to restore the DB itself, it looks in the volhistory file to find the last good DB backup. It will see the pointer in volhistory to the disk file and use it. (I recommend you put a copy of devconfig and volhistory in your rootvg, also.) If you specify yourself which "volume" TSM uses for the DB restore, you just give it the name of the file. It all works. -----Original Message----- From: Bill Wheeler [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 10, 2002 3:14 PM To: [EMAIL PROTECTED] Subject: Re: TSM DBBackup Here is the scenario that I was planning if I can get the DBBackup to go to a flat file. Run nightly archive to LTO device Run DBBackup to flat file located on rootvg of AIX box Run Mksysb of rootvg to 4mm tape. If this is sufficient, my only other question is how do you restore the DBBackup, is it the same as if you are restoring it from a tape? Bill Wheeler PDM Administrator -----Original Message----- From: Michael Benjamin [mailto:[EMAIL PROTECTED]] Sent: Monday, July 08, 2002 9:53 PM To: [EMAIL PROTECTED] Subject: Re: TSM DBBackup Hi Alex, If you've tarred the file to LTO, how do you utilise it quickly? It's almost easier to let TSM perform the dbbackup to LTO, and then you have a dbbackup volume you can utilise straight away. The dbbackup takes a few minutes to complete, time is a non-issue here. Yes it's a shame you have to waste a lot of space on the dbbackup volume, but it's the same type of volume and that's worth a lot... I guess you have to work out how much your data is worth, if it's more than about $1000 AU then it's definately worth buying some more tape volumes to rotate your DB offsite. The DB is simply too important to mess around with and lose... that single volume represents the entire contents of your server, if you lose that and your db/mirrors on the filesystems your 10,000 tapes aren't worth a thing to you come recovery time they are just a massive collection of ones and zeros... Mike. > -----Original Message----- > From: Alex Paschal [SMTP:[EMAIL PROTECTED]] > Sent: Tuesday, July 09, 2002 1:26 AM > To: [EMAIL PROTECTED] > Subject: Re: TSM DBBackup > > You can do a dbbackup devc=file_class, which will put the dbbackup into a > file on disk. The only thing is you'd then have to script a process that > somehow backs up that file, or do it manually. Possibilities include: > > FTP to remote site > tar to 4mm tape > tar to LTO > > Personally, I'd rather not run so tight on scratches that I don't have 7 > tapes I can spare for dbbackups. > > Alex > > -----Original Message----- > From: Bill Wheeler [mailto:[EMAIL PROTECTED]] > Sent: Monday, July 08, 2002 6:30 AM > To: [EMAIL PROTECTED] > Subject: Re: TSM DBBackup > > > Currently we run our archive to a Magstar 3570 tape subsystem. Once the > archive is complete we run the DBBackup to a new 3570 scratch tape. The > issue is that the DBBackup is so small at this point; we are looking at > options to find a way to back it up differently. On an LTO tape we might > us > 1 to 2 GB, and cannot see wasting 98 GB (uncompressed). If we could put > both the archive and DBBackup on one cartridge that is the way we would > go. > If not, can the DBBackup be put to a flat file where it can be restored > from? We would like to make sure it is the same type of tape volume that > we > are using, we just want to make sure that it is cost effective. > > Bill Wheeler > PDM Administrator > > -----Original Message----- > From: Michael Benjamin [mailto:[EMAIL PROTECTED]] > Sent: Sunday, July 07, 2002 9:23 PM > To: [EMAIL PROTECTED] > Subject: Re: TSM DBBackup > > At the end of the day, sometimes it's easier to go to the same type of > tape > volume. > > For example, if you have a DR situation, you will need to source another > library/tape drive > if your DB exists on another form of tape volume. This is a very poor > approach when time > is of the essence in the recovery situation. Same goes if your secondary > drive/library fails, > you will need to start backing up to the LTO anyway, multiple points of > failure. > > Secondly, the LTO will write the DB very quickly to tape and continue on > it's merry way. > You can also track these tapes with the same library, and rotate say 7 > dbbackups offsite and > expire them for maximum safety, how cool is that? > > Cutting corners to save a couple of bucks makes no sense at all when the > aim > is the security > of your data. A few hundred bucks of tape is worthwhile....... > > Mike. > > > -----Original Message----- > > From: Bill Wheeler [SMTP:[EMAIL PROTECTED]] > > Sent: Friday, July 05, 2002 10:22 PM > > To: [EMAIL PROTECTED] > > Subject: TSM DBBackup > > > > Hello *SMers, > > > > > > > > I have a couple of questions. We are possible moving to an > > LTO > > drive in the near future. I am trying to determine how to do a TSM > > backup > > without sending it to a separate cartridge. Our DBbackup is small and > do > > not see a reason to use such a large cartridge, do anyone have an idea? > > > > > > > > Can it be sent to the same cartridge? > > > > Can I create a flat file and back that up? > > > > > > > > > > > > These are the few questions that I need an answer for, if any one could > > help > > me out. > > > > > > > > Thanks, > > > > > > > > Bill Wheeler > > > > PDM Administrator > > > > La-Z-Boy Incorporated > > > > (734) 242-1444 x 6170 > > > > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > ************************************************************************** > Bunnings Legal Disclaimer: > > 1) This document is confidential and may contain legally privileged > information. If you are not the intended recipient, you must not > disclose or use the information contained in it. If you have > received this e-mail in error, please notify us immediately by > return email and delete the document. > > 2) All e-mails sent to and sent from Bunnings Building Supplies are > scanned for content. Any material deemed to contain inappropriate > subject matter will be reported to the e-mail administrator of > all parties concerned. > > ************************************************************************** ************************************************************************** Bunnings Legal Disclaimer: 1) This document is confidential and may contain legally privileged information. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this e-mail in error, please notify us immediately by return email and delete the document. 2) All e-mails sent to and sent from Bunnings Building Supplies are scanned for content. Any material deemed to contain inappropriate subject matter will be reported to the e-mail administrator of all parties concerned. **************************************************************************
