1 / 13

Tales of a TSM Implementation

Tales of a TSM Implementation. Peter Smith Bendigo Bank Ltd. Agenda. Why Did we Move to TSM ? Major Components of our TSM Implementation TSM Architecture Summary of TSM DAILY Backups Summary of TSM MONTHLY Backups How we handle “LongTerm” Backups Summary of TSM Operations

gwidon
Download Presentation

Tales of a TSM Implementation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Tales of a TSM Implementation Peter Smith Bendigo Bank Ltd.

  2. Agenda • Why Did we Move to TSM ? • Major Components of our TSM Implementation • TSM Architecture • Summary of TSM DAILY Backups • Summary of TSM MONTHLY Backups • How we handle “LongTerm” Backups • Summary of TSM Operations • Data Storage Policy • What we’ve learnt along the way • Future Plans

  3. Why did we move to TSM ? Backup Window unmanageable • FileServer (560Gb) & SQLServer (680Gb) taking approx 31 hours each for a month end backup. Leaves little/no room for error. Restores delayed due to transport of tapes. • Backup from last night lives at Vault. Most restores require a trip to vault to retrieve relevant tape. No redundancy of Tapes • Only a single copy of each tape is kept. If a tape becomes corrupt then all data on tape is lost. Cannot rebuild tape.

  4. How is TSM architected ? • Major Components • TSM Server located in BBL Data Center • DR TSM Server located in BCC • Disk Storage Pools on SAN located in BBL Data Center • Primary_Data 200Gb • SQL_Data 10Gb • 3494 ATL with 4 x 3590 Tape Drives located at BCC • TSM Clients

  5. Architecture Diagram

  6. Summary of DAILY TSM Backups • By default data is backed up to a disk based storage pool • Large files eg SQL backup files are sent directly to tape based stgpools • Whilst a file exists on the LAN a backup copy is kept indefinitely • If the LAN copy of a file is deleted the backup copy is kept for 1 year from deletion date. After this date the backup copy is also deleted. • dsmc executed from client to invoke backup

  7. Summary of MONTHLY (LT) TSM Backups • <node> is re-registered with server as <node>_LT • <node>_LT is assigned LT client options file (retain for 7 years) • dsm.lt.opt with “nodename = <node>_LT” is created • Backed up to disk based storage pools • dsmc –nodename=<node>_LT –optfile=dsm.lt.opt executed from client to invoke backup(same .bat file as DAILY backup) • All modified data since the last longterm backup

  8. Monthly (7 year) Backups

  9. Summary of TSM “Operations” Daily • Backup client data to disk / tape • Create “offsite” copy of all backed up data • Migrate disk based storage pools to tape • Expire data according to “management class” • Run DR operations • Backup TSM DB to Tape and Disk • Copy TSM DB to DR server • Copy scripts, prepare plan, volhist, devcnfg to DR server • Run “reclamation” for tape usage optimisation Monthly • “colocate” top 10 clients

  10. Data Storage Policy Client Option Sets System / Application disks = BA_7DAYS_MC Data disks = BA_31DAYS_MC <nodes>_LT always configured with LT_FILE_MC (takes precedence over all other MC)

  11. What we’ve learnt along the way (1) • Keep on top of TSM Service Packs • Closely monitor tape drive activity • Rogue activity can quickly deplete “scratch” volumes • Consider an alternative to TSM Scheduler • Don’t rely on the GUI • Get to know the cmd line, basic SQL cmds • Design your own reporting • Research TDP’s carefully • Watch changes to MC very closely • Consider the default MC • Get the “business” to define data retention rules • Have a costing structure

  12. What we’ve learnt along the way (2) • Don’t get caught without scratch tapes • 2 tape drives are not enough • Locate the DB on a disk with room for growth • Perform regular reclamation • NewsGroups / UserGroups are your friends • Be careful with firewalls / VLANS

  13. Future Plans • Implement TDP backups • Build a “costing” model • Performance Tuning • Delegate “restore” authority • TSM in regional hub sites • Consider moving to larger capacity tapes

More Related