Zlatko, I am so tired of hearing about this. You "hit the nail on the head" as we say in the USA. Let me see if I can put some sense of reality into this once and for all. In the mainframe days we designed applications to have cycles of processing where you could roll all the data up and recover to any point in a financial processing cycle. Typically, these were monthly and yearly, but sometimes quarterly and weekly were important for special sales information. Somehow, I do not know how, the open systems world has extrapolated that taking backups on these schedules is the same thing and it simply is not. In the mainframe model the application had the data files on tape named weekly, monthly, quarterly, yearly, and had all the intermediate files that could recover each of the tapes or created 2 copies of them. In any case all of the intermediate transactional data was there because mainframe integrity was paramount and tapes did fail, but the data was always recoverable because the application design, not the backup system. The backup system was for hard drive failures, disaster recovery, and TSO data files of end users. End users, we just kept 1 to 13 backup copies, period, that is all they had. In the open systems world everything looks like TSO data so the parameters in the backup product (TSM) had to be changed to allow for more copies and retention by time in place of or in extension to the number of copies.
It took me a long time to convince my management they could not recover anything with any assurance with NetBackup. They could not tell the customer what the recovery would be except that it would be a long ways back if at all. Now, TSM arrives, and we are well again. I keep the data backups for the retention the customer dictates not as the backup product dictates. It is possible to achieve with 4 nodenames per node what they are all talking about here. But, as you say, "ask them what they want to restore". Then, you find out what the business requirement is. We will eventually pound this into the folks that think weekly/monthly/quarterly/yearly archives are dumb and provide no sense of recovery. The reason it was done is so you had some kind of tape to fall back to if one was bad, but today, that is so much lost data it is a disaster. You have to do your normal cycle and copy it, period. And, in our case, copy it for an onsite copy and an offsite copy, because if you have a disaster while you are rebuilding a failed primary tape from your offsite copy, you have just lost your disaster recovery set. Now, the issue of affordability eventually kicks in. That is where you have to decide how think the pad is you where on your butt. Is it 1, 2, 3, etc. copies. TSM can do that, but there is a price. But, as you say there is no "limitation" with TSM. You can do it. It is just not tape retention, it is object retention. If we could just get people to think in terms of backup object retention versus tape retention and understand that paradigm, I think we would be there. Take me back to my good old mainframe. Paul D. Seay, Jr. Technical Specialist Naptheon, INC 757-688-8180 -----Original Message----- From: Zlatko Krastev [mailto:[EMAIL PROTECTED]] Sent: Friday, July 05, 2002 11:06 PM To: [EMAIL PROTECTED] Subject: Re: Client Archive Weekly/Monthly/Quarterly/Yearly Yes, by setting weekly/monthly/quarterly/yearly schedules and corresponding management classes and copygroups. But first try not the drive the Ferrari you have as a pram. Periodical backups are *limitations* of a product not features. Ask your people what they want to restore not how to achieve it. 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: Client Archive Weekly/Monthly/Quarterly/Yearly Does anyone know of an easy way to set up archiving of clients data on a weekly/monthly/quarterly/yearly basis. Thanks Steve Figel Storage Consultant Salem Group 336.744.5999 (ext 1290) 336.414.0224 Cell [EMAIL PROTECTED]
