What I would do is simply this: Keep the backups and archives separate, and consider this:
Set-up a policy for each server that requires different rules. Keep point in time backups for as long as is practical on each management class. You can even separate the management classes into different storage pools to help keep things straight. A low retention pool could be on disk even. Then, choose the client nodes that have a requirement for archive. Assess archives carefully so as to cut costs if possible. Then, you can extract a 'snapshot of data' from existing backup pools using create backup sets, and catalogue them using a 3rd party product called Code Relief. I use this method and run the archives on Saturday. It gives me the latest data for that week, and I end up with a 52 week x 7 year archive. You could easily make this happen daily, but the advantage is that I don't tax the SAN/LAN/WAN for archives, the archives can be restored without the server (LAN-less) and Code Relief is ALOT less than DRM (DRM doesn't catalogue backup sets, and code relief does), and performs all the same disaster recovery conventions. The down-side is that code relief only runs on Windows (ack!) but it can work with an AIX server via ODBC. Dunno if that helps, but anything is better than losing the incremental forever paradigm (imho). Good Luck! Kevin. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Seay, Paul Sent: December 5, 2001 1:26 AM To: [EMAIL PROTECTED] Subject: Re: Need help on TSM offiste DR setup. First of all, the 5 year requirement is probably a business requirement from some financial people or legal department. The question becomes what granularity of recovery they want. I presume you run daily backups. So, lets say for a minute that all data revisions must be kept for 5 years. That would require up to 5 x 365 versions and an expiration of 5 years. Now, if you are doing INCR type backups remember the files only get backed up on every change. If you are doing SELECTIVE you may want to reconsider to reduce the number of backups. Now for the piece you may not have considered. The business may also need to keep the deleted versions for 5 years. Too often as technicians we start compromising the amount of data kept without having the proper knowledge or backround to make the cut-back decision. Let's take the example of a medical record. When can I cut out some of the information? The answer is never. Bank records are similar. Engineering changes are similar. Manufacturing inspection records are similar. The best decision is to go to the business and let them determine the legal and business requirement. Design a solution and tell them what it cost. Consider your old paradigm. After 1 month, all the daily revisions are lost. After 60 days, you have only the monthly revision snapshot (what good is that?). Ask your business the right questions and you will be able to design a matching solution with TSM. The closest you can probably get to what you were doing before is Backup Sets. Your email should be put in a different management class. That is easy to do, depends on the email system and which TDP you need. Good Luck. -----Original Message----- From: LY, Tuan (Kanata) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 04, 2001 11:08 AM To: [EMAIL PROTECTED] Subject: Need help on TSM offiste DR setup. Hi All, We are currently using TSM 4.1.1 ( dual CPU) on AIX 4.3.3 with the 3584 Lib.I have recently completed the migration of all the servers backup from Arcserve to TSM. I would like to get inputs on how to implement the TSM policy vs the old Arcserve traditional backup method. On the TSM, we have setup two primary diskpools, collocated (82 GB) and non-collated (24 GB) and one copy pool for offiste storage (TSM DRM). 1) Old days Arcserve backup : Daily - keep 30 days Weekly - 1 month Montly - 7 years Yearly - forever What happened is most of the sysadmin did not give me a clear direction on the policy. All they say was keep the backup strategy as before ( mentioned above ) . And on TSM, they want to be able to restore any copy of file within the 5 years time frame which I think is too much. Right now, I'm backing up about 30 servsers with the policy of keeping almost everything for 5 years.The nightly backup data transfer is about 70 GB. However there are 50 GB of data that is belong to mail database which I don't need to keep for 5 years but I still need to keep the monthly one for two years and daily for 30days. Right now, the TSM has been running just over a year and I can see my offsite copy tapes are increasing. This doesn not help for lowering the offsite storage cost and also my DB vol is getting full (4 GB 70 % utilized) which is fill up quicker that I have planned. I heard that there is a limitation on TSM 4.1.1 that the log vol can not growth bigger that 4 GB ? My question is, instead of sending out 70 copy pool tapes for offiste storage. What is the best way to setup with the TSM policy like the old backup method mentioned above and be able to make a copy of full backup of all the servers at the most current state and put them on a set of tapes and send them offsite as for fulll backup and for DR purpose as on the weekly basis. My goal is to have a copy of all the most recent copy of full backup on all servsers and instead of having 70 tapes sitting offsite, with the proper setup, I only need to send let say 20 tapes offsite on the weekly basis. Since I have only two days of windows on the weekend, I'm not sure if I can have all the server's full backup done on time for Monday to send them offsite. So, what is the best way to implement, backup sets, archive, or image backup ? Do I have setup a third and fourth stgpool (Archive and monthly) ? Will any of these method help to lower the tape usage and verions. ( Instead of keeping everyting for 5 years, and if the weekly full backup work, hopefully I can lower the retention of files and versions from 5 years down to 2 years or even can apply shorter retention time better versioning control). OS Platform : TSM CLIETN 4.1.2.19 for NT 4, WIN2K TSM CLIENT 3.7 for HP-UX 10.2 Thanks for your time and your input will be greatly appreciated. Tuan Ly MDS Nordion [EMAIL PROTECTED]
