I think having your log in roll forward mode is a no-brainer. As long as you have enough log space it's not even an issue... What's the limit now, like 15gb or something? Wanda, with all the activity you have going on how much log space usage do you see between database backups???
Mark -----Original Message----- From: Zlatko Krastev/ACIT [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 18, 2002 4:32 AM To: [EMAIL PROTECTED] Subject: Re: DB backups Wanda, in general I am on your side but some of the arguments are weak: 1. stgpool backups If the DB is reverted back newly created copypool tapes will be listed as scratch and primary pools' objects will have no copies. Next backup to this copypool will fix the things and probably will use same scratches. 2. tape reclaims Similar as above for reclamation destination tapes and reuse delay protects reclamation source tapes 3. expiration It can be performed again without data loss. Yes, for large DBs time for expiration is an issue but the only penalty will be larger first expiration *after* recovery. 4. HSM client bringing a file from TSM back to host Again no data loss. Option to backup the file *before* migration ensures we will have a copy to restore from. Now other arguments. Besides some remarks I prefer roll-forward mode :) - you already pointed hundreds of desktops backing up around the clock. Sites which *do* backup desktops very often cannot have all of them available at night. And you cannot predict when a mobile user will be online or in the office. - RDBMS servers perform backups during normal window but transaction logs are coming throughout the day regularly. - archives - user archived a set of files, got successful completion result and does not care further. - some applications use TSM as *the only* storage, example IBM CommonStore - loss of last minute TSM DB updates will lead to loss of created/revised documents. After data came in TSM our task is to protect it. Even with new functionality of v5.1 loss of DB updates will lose track of both copies. Zlatko Krastev IT Consultant Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: DB backups For some environments, yes. But not for all. Even people who backup once overnight, still have to do (1) backup stgpool to create copypool tapes. (2) tape reclaims (3) inventory expiration All those things change the TSM DB. And some environments are really 24 x 7: One of our TSM servers does desktop backups of 500+ clients. Backups are spread over 24 hours a day, so for that environment, the TSM db is changing EVERY MINUTE. Really. And consider also the people who have implemented the HSM client - in that environment, just having a user "touch" a file is enough to bring it back from TSM storage to client storage, and the TSM DB is changed. In either of those environments, losing 12 hours, on average, of DB changes can be devastating. ************************************************************************ Wanda Prather The Johns Hopkins Applied Physics Lab 443-778-8769 [EMAIL PROTECTED] "Intelligence has much less practical application than you'd think" - Scott Adams/Dilbert ************************************************************************ -----Original Message----- From: William Rosette [mailto:[EMAIL PROTECTED]] Sent: Monday, June 17, 2002 8:52 AM To: [EMAIL PROTECTED] Subject: Re: DB backups You can get "up to the minute" if you do enough database backups, and I still don't understand the "up to the minute" idea. If you are doing backups every minute that seems logical but do not most people backup once a night? and if there is a database backup is not this database backup and "up to the day" same as "up to the minute?" "Jolliff, Dale" To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: OM> Subject: Re: DB backups Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED] IST.EDU> 06/14/02 12:21 PM Please respond to "ADSM: Dist Stor Manager" I have suggested this a couple of times, but have been told they need the ability to restore the TSM server "up to the minute" that rollforward provides. -----Original Message----- From: William Rosette [mailto:[EMAIL PROTECTED]] Sent: Friday, June 14, 2002 9:49 AM To: [EMAIL PROTECTED] Subject: Re: DB backups We changed our roll forward to NORMAL and have seen very little (once in a year) crash due to full recovery log. This may be an option instead of the type FILE. "Jolliff, Dale" To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: OM> Subject: DB backups Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED] IST.EDU> 06/14/02 10:01 AM Please respond to "ADSM: Dist Stor Manager" Is anyone doing db backups to disk using devclass type FILE? I know, it's not necessarily a good thing, but right now we have a db that is large enough that the log can fill before a full db backup can run. Before I set this up, I'm wondering if anyone else is doing this. Confidentiality Note: The information transmitted is intended only for the person or entity to whom or which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please delete this material immediately.
