>> On Thu, 10 Aug 2006 12:10:09 -0500, Dave Mussulman <[EMAIL PROTECTED]> said:
> I do my backups to a DISK pool that has a 85/40 migrate percentage and a > tape next storage pool. If everything (my disk and tape pool) is synced > up to my copypool before a backup runs, and the backup only goes to > disk, the 'backup stg' for the tape has nothing to do. I understand > that. If I backup the disk pool and manually migrate the data from disk > to tape, and then backup the tape pool, it has nothing to do. (Since > that data was already in the copypool.) I understand that. But, if > during a backup the tape pool starts an automatic migration, the next > time I do a 'backup stg' for the tape pool, it has data to copy to the > copypool. So, what's happening? Migration begins for a particular node or collocgroup, and then completes for that node or collocgroup ("node-ish") before moving to the next one. If that node-ish has backed up more stuff since the last backup stgpool completed, then the uncopied data will get migrated too. Said from another direction, TSM doesn't worry about selecting only backed-up data from a stgpool when it's migrating, it takes whatever is there. Defining a copystgpool for the destination of the migration is advertised to help with this: It's claimed that data will be simultaneously written to the target primary pool and the copy pool. I have not been able to elicit this behavior myself, and am somewhat grumpy therefore. > Best practice-wise, do you try to define different private groups > and tape labels for onsite, archive and offsite storage? Or do > people really just make one large 'pool' of tapes and not care if > tape 0004 has archive data on it and stays for years, 0005 goes > offsite, 0006 has a two week DB backup on it, and 0007 is a normal > tape pool tape? Your recordkeeping problem is too complex to do by casual inspection, even if you separate the classes as you suggest. Work out queries against the database that satisfy your auditing notions, and trust them. Oh, and run them. ;) You will inevitably end up needing more "Primary" tapes when all you've got on hand will be labeled for "Reverse thudpucker" use or some such; Then you'll cross your own lines, and after the first time it gets easier and easier.... Reminds me of the first time I checked all of the volumes in a copystgpool out of my library. "Just this once", I thought. But once you're there in the back seat.... Uh. Digression. > I have a LTO3 tape library and an external LTO3 drive. In our > Networker environment, we found it a pretty good practice to have a > drive outside of the jukebox for one-off operations (old restores, > etc.) as well as some sort of fault tolerance if the jukebox or that > SCSI bus went south. How do I setup that environment in TSM? Having an extra drive outside a library isn't exactly a _bad_ idea, but unless you're trying to write a different format I'd expect you to get more value out of adding it to the library. The purposes for which we'd like external drives are mostly what are called "backupsets", intended to be used independant of the TSM Server, written in media formats accessible to drives directly attached to the clients. If you really, really want to do this, I'd suggest: - Define all of the drives to be "in" the library. set the one which is physically outside to usually be offline. - When you want to use the external drive, set the interior drives offline, the exterior online. Run the job, mount, dismount, etc. - When you're done, re-set to normal operations. Personally, I'd much prefer checkin and checkout of desired volumes to this. And get a quote on how much the next bigger step of library is, and count the amount of time you spend screwing around with inadequate library space. That way you can demonstrate to the folks who are hoarding the beans when they start losing money because they didn't cough up a library at the outset. TSM is tremendously economical with tape and drive resources compared to other backup products. Feed it well; feed it hardware instead of your time. > Consolidating copypool tapes for offsite use.I had my reclaimation > threshold for my copypool at 40%. I used 'backup stg' with maxpr=[# > of drives] to minimize the amount of time the backup took. In proper consultant fashion, I'll tell you the time with your watch. You minimized the "time the backup took", and then found that this minimization squoze out, maximizing another part of your workflow. Now, if you were me, you'd try to develop a theory of copystg utilization workflow, and solve it for a minimum. But I suggest you just twirl the knob to the other end, and see if you like that tradeoff better. So 'backup stg' with only one process, accept that it'll take longer, and see if that's quick enough. If you can get a little bit of offsite reclamation accomplished in most of your rotation cycles, then you're doing pretty well. > I'm believe I understand the way a DR scenario should work with > copypools and a complete DB restore from an offsite tape. (We're > not production with TSM yet, and that's still on my list to > test/learn.) I'm not as confident about the scenario where the > database is intact, but I want to restore some data that still > exists on copypool tapes but has been expired from the active > database? You should consider data which has expired to be Gone, except for heroic measures. If you Really Need data which expired out of the database in the last week or so (a common period for retention of DB backups) then yes, you can do a complete DR scenario, and consult the as-yet unreused tape volumes for the data. Icky squicky. > (Or is the standard BOFH answer "We don't do that." and adjust the > copygroups so that the revisions they need are kept on the server, > or fall back to archives or backupsets?) It's sufficicently easy to set your retained versions foolishly high; I don't even consider the "We don't do that" to be a BOFH-style answer. It's usually an answer like 'You messed this up last month, overwrote it every week and didn't notice until the first of this month, and have waited until NOW to ask me to get it back? No, it's gone.". - Allen S. Rout