Nick hit the nail on the head: prioritize the restores. Know long before what actually has to come back and how quickly. Then take a look at how the data is getting onto the tapes. Do this for both on-site and off-site tapes and you cover the daily restore and the disaster restore.
It turns out that a lot of data is naturally collocated. That is a "full" backup is all in one place. Take a SQL or Exchange database backup. The agent backs up the whole thing, the whole thing gets moved to tape during backup stg and during migration. Natural collocation. Nick's SAP database is a different beasty, but he has a plan. Does he move a lot more data? Probably not a lot. Especially if it's important during a restore. So with a little thought and Nick's cleverness you can handle the database problem. What about fileservers? There is really no easy answer. By their nature they are very hard to restore. You can't collocate the offsite data. Collocation does handle the on-site restore reasonably well unless the server is huge then all bets are off. Only thing to do there is break it down. DR is probably nigh on impossible in any reasonable amount of time from copy storage pool tapes. Backupsets? Anybody done one of those for a 500 GB file server? I'm thinking probably impractical, but I'd love for someone with a fileserver of this size to try it and report what they learn. That'll just grab up a tape drive for a couple of days is my guess, but who knows? If this works then periodic backupsets taken to the offsite augmented by copy storage pool incrementals. The other nice thing about this approach is that you can dedicate a tape drive to the server doing the restore and get on with the rest of your TSM restores. You know the really good news is we hardly ever have to do these restores. But when we do we had better have a pretty good plan. Or a pretty good resume. Kelly J. Lipp Storage Solutions Specialists, Inc. PO Box 51313 Colorado Springs, CO 80949 [EMAIL PROTECTED] or [EMAIL PROTECTED] www.storsol.com or www.storserver.com (719)531-5926 Fax: (240)539-7175 -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Nicholas Cassimatis Sent: Tuesday, December 18, 2001 3:57 PM To: [EMAIL PROTECTED] Subject: Re: Incremental forever -- any problems? The one topic no one is mentioning is Disaster Recovery. It's very hard to collocate an offsite pool. The only way to reduce the number of tape mounts is to do some type of full backup periodically (either backup or archive). I started doing "full backups" of SAP filesystems after doing a DR with two 3590-B11's as my 3494 tape library. After 1800 tape mounts to restore /saparch, something had to be done. Watching TSM restore 1 file from each tape made it imperative. "Full backups" was the something (Note the quotes - see below). Taking "full backups" periodically drastically reduces the number of tape mounts needed to restore at a DR, since the data should not spread across more tapes than the number of days since the last full backup. So our 1800 mounts above comes down to 7, if weekly fulls are taken of the systems. Now comes the argument of "That's duplicating a lot of data!" Yes, it does. So figure out what needs to be restored in this way (the answer is "Not all of /saparch" for you SAP accounts out there) to bring the system back up in case of a disaster. Work with data owners to see what they need back immediately, and what can wait until after the system is back online and running. There's more in that second list than you may think! My "Full Backups" are therefore weekly archives of critical path data, which are kept for 2 weeks. At a DR, I do a retrieve, then a restore of the incremental data since the archive (then I script the retrieve and restore, just to speed it up even more, but that's a different thread). Nick Cassimatis [EMAIL PROTECTED] Today is the tomorrow of yesterday.
