Hi, this is typical question from people moving from classical backup systems. I had to switch my mind as well as I started with TSM.
Keep in mind, the requirements your customer has are most likely not pure business requirements, but his historical requirements adapted to both existing and missing functionality of classical backup methods. You will find tons of discussion about it in http://msgs.adsm.org/cgi-bin/get/adsm-current.html . Best start is to let your customer define his real business needs (needs, not dreams) without thinking of any technical limitations, then explain him how the solution in TSM could look like and let customer re-check and trim his needs so that costs would not explode. Technically you would be most happy if you can fulfill most of real needs with incremental backup & management classes, even if you keep some file copies more than really required, and maybe use few backup sets or archives for long-term backups. Show your customer the basic disadvantage of his current strategy: * it is quite nice to keep "year" tape for five years, but there is NO file on it which was both created and deleted between two such snapshots - the granularity is one year. As long as you can go with incremental approach you are likely to have granularity of one day, if you keep , for example, an extra version of each file for five years, and up to 31!? active versions of a each file, then your customer maybe will lose versions for year-1, year-2, year-3,year4, but he will NOT lose then you probaly will not lose many files(*). For small file groups of relatively small files you can even easily offer 5*365 versions, this is something he could not be offered with classical backups, and it works perfect. If he still insist on "year" backups of whole filesystems, supply him with archives or backup sets as well. There are two drawbacks with long-term incremental backups : the minor one is database size growth, the major one (in my mind)is that the backup will eventually lose track if your file paths are changed, and will probably expire old versions which vere suggested to be kept longer. This happens mostly if you migrate/consolidate servers or file systems. If you are unix man, virtulamountpoints may help. regards Juraj Salak -----Original Message----- From: Paul van Dongen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 16, 2002 1:55 PM To: [EMAIL PROTECTED] Subject: Different retentions for same file Hello all, I am planning a TSM implementation ata customer who has another backup solution already in place. They want to slowly make TSM take over all backups, but they don4t want to suddenly change the work done by the production people, who take care of all tape movements. The present backup solution works using different retention times for the backed up files: the daily backups are kept for 20 days; the saturday ("weekly") files are kept for 40 days; the monthly backup is kept for 100 days, and there is a "year" backup that is kept for 5 years. The question is: I could make this using backups for the daily processes, and to use archives for the other ones. But there are TDP4s involved (SQLServer, Exchange and DB2) who always do backups, and if I use something like different management classes, I would get a lot of rebinding problems. Would backupsets be the answer? Any ideas would be greatly appreciated Thank you all -- Paul Gondim van Dongen Engenheiro de Sistemas VANguard - Value Added Network guardians http://www.vanguard-it.com.br Fone: 55 81 3225-0353 ------------------------------------------------------------------- Este e-mail foi enviado pelo site da Nlink: http://www.nlink.com.br
