二十个不可不知的 TSM 知识点
你可能是個TSM 新手，也可能是個TSM 老手，但這20個知識點不一定都清晰。
https://www.sohu.com/a/218745936_151779
背景知識：TSM能做什么？
Tivoli Storage Manager(簡稱TSM)是IBM的一款備份軟件，能夠為大型的企事業單位提供可靠的集中數據備份管理，是業界最主要的備份軟件之一。TSM支持以下類型的數據備份：
基本文件的備份歸檔：基于普通文件類型的備份
操作系統基本的裸機備份：支持aix、linux、windows、solaris等主流操作系統
數據庫的備份保護：支持oracle、sql server、db2、informix等主流數據庫備份
SAN 備份模塊：支持lanfree的傳輸模式備份，提升備份效率
NAS設備支持：支持NDMP協議備份，對netapp和emc的nas設備提供原生支持
ERP備份：支持SAP備份，包括基于hana的SAP
郵件系統備份支持：支持基于MS exchange和lotus nodes的備份
一般來講，我們需要如果需要對某款應用進行保護，安裝對應的模塊即可。比如，需要對oracle數據進行保護。需要安裝如下模塊：
tsm server：服務端
tsmba client：基本客戶端模塊
tdp for oracle：tsm備份oracle的模塊
tsm for san：可選，lanfree模塊
背景知識：TSM的架構和概念
TSM作為一款功能強大的備份軟件，底層有著自己清晰的邏輯架構。要想學好并靈活的應用tsm軟件，需要對TSM底層的架構及相關概念有一個清晰的掌握。在TSM的架構中，主要分兩大塊：
1.策略層：含以下概念
-
策略域：相同或相似節點數據保留需求的一個集合體，其下包含策略集。
-
策略集：策略域的子集，每個策略域中可以有多個策略集，但只有1個是激活的。
-
管理類：策略集的子類，一個策略集中可有多個管理類，但只有1個是默認的。
-
副本組：管理類的子類，每個管理類中最多只有2個副本組，按功能分備份副本組和歸檔副本組。副本組中指定數據存放的策略，并執行存放的位置-存儲池
2.存儲層
-
庫：磁帶庫，實際上指的是機械手
-
驅動器：磁帶庫中的磁帶機
-
設備類：區分不同類型存儲的邏輯概念。
-
存儲池：根據設備類的不同，使用不同的存儲介質組成的邏輯存儲集合
-
卷：根據不同情況，可能是磁帶。也可能是文件或設備。
物理存儲設備和邏輯存儲概念通過設備類關聯起來，存儲層和策略層通過副本組關聯起來，下圖：
、
TSM 20個常見問題和難點
1、TSM支持各種主流操作系統的備份，實現方式是什么？
windows、linux、aix：cristie公司的cbmr或tbmr，支持操作系統的備份。和ibm有合作關系，好像可以買tsm的時候一起下單。可獨立使用，可集成到tsm里，受tsm統一調度管理。同時支持win linuxaix。恢復的時候需要使用cbmr的引導光盤。獨立收費，需要激活碼。首推的，非常好用。除了這些，cbmr還支持hp-ux和solaris的系統備份。
aix：sysback，ibm自己的aix系統備份工具，優勢是免費，集成度高。劣勢是必須搭配nim使用。也就是說你環境里至少2臺小機。配置復雜。
windows、linux：早期還有fastback，ibm自己的快速備份軟件。支持win和lin操作系統的備份，屬于獨立的產品線。現在產品線已經停了。
2、TSM 能否備份VMware ESX下的虛機？
首先，從VMware的備份來講，VMware有兩種備份實現方式
VCB: 需要額外的proxy服務器和空間，如1T的虛機空間，還需要額外的1t空間來存放備份數據
Vstorage API(也叫VADP，vStorage API for Data Protection)：2009年推出，可以直接從vm存儲上傳到備份服務器空間，VADP服務器可以是虛擬機。tsm支持通過vadp執行文件級別的備份
TSM的ba client直接支持vmwarevm的備份，但是安裝tsm for ve后可以支持高級特性。Tsm for ve基于VADP技術實現，支持esx下虛擬機的備份。更新到TSM V7以后，tsm for ve也有了較大更新，具體可參考官方的技術更新：
http://www.ibm.com/support/knowledgecenter/SSGSG7_7.1.0/com.ibm.itsm.ve.doc/r_techchg_ve.html
3、TSM 對數據庫的保護如何實現？
目前，TDP for Database支持MS sql server、db2、oracle等主流數據庫。對于sql server和oracle來說，需要購買TSM FOR DATABASE模塊，然后安裝對應的模塊來實現；對于DB2來說，安裝TSM的ba client即可直接支持，不需要額外購買相應的模塊。
對應各數據庫來說，TSM的備份模塊僅提供了備份通道，實際上還是通過數據庫自身的備份工具來實現。以oracle為例，在安裝配置好tdp for oracle后，備份還是使用rman，僅通過tdp的通道將數據備份到tsm所管理的磁帶庫中。
4、TSM系統部署流程是怎樣的？需要做好哪些準備工作？
1，備份系統的整體規劃，包括存儲架構，主機的部署，備份方案的確定。
2，tsm系統的安裝配置，初始化。
3，備份服務器的配置，策略域的設置，存儲池等。
4，客戶端的實施，安裝tsm軟件包并配置。
5，備份恢復測試。
5、TSM系統在首次部署時關注點有哪些？
1，你需要知道你要備份的是數據庫還是操作系統，決定了你要選用的tsm模塊
2，備份的數據量有多大，能否在規定的時間窗口內完成備份
3，為了在規定的時間窗口內完成備份，對磁帶庫有哪些要求
4，如果有同城備份選用什么傳輸線路？帶寬具體多少能滿足要求，這些都需要考慮
5，未來數據量增長的趨勢，盡量建成備份系統后，滿足未來1~3年的數據增長需求
6、TSM 保本版本參數詳解
verexists：指定當前在客戶機文件系統中的文件所保留的最大備份版本數，如果某個備份操作超過了限制，則服務器使磁帶庫中最舊的備份版本到期。（即代表文件系統中有的文件在磁帶庫中保留的版本數）
版本數既文件的個數，比如verexists=2 ,則有文件/backup/file1，第一次備份保留一個版本，第二次備份，又會重新備份一次，同一個文件總共2個版本，但可能文件內容不一樣了(因為文件被修改了)。
如果verexists=1，則第二次備份時，就會將第一次備份的文件刪除掉，保留第二次最新的版本。
最新的版本叫ACTIVE的版本，其他的版本都叫INACTIVE的版本。INACTIVE的版本可以通過 QUERY -INACTIVE參數查詢出來。但一旦版本保留時間超過了retextra規定的保留天數，則TSM將把版本變為過期的(expire)，用-inactive參數無法查看到。只能釋放掉文件(expire inventory)。
verdeleted：指定要保留的文件備份版本的最大數目，該文件經TSM備份后，已從客戶機文件系統中刪除。
如果用戶從客戶機文件系統刪除文件，則下一次備份導致服務器讓超過此數值的文件的最舊的版本到期。保留版本的失效日期由RETEXTRA和RETONLY參數指定的保留時間決定。
此參數就是說如果主機上刪除了這個文件，那么TSM中繼續保留多少個版本數。如果verdeleted=0,則主機上刪除了文件，則TSM也將文件刪除掉。沒有起到備份的意義。verdeleted=1代表如果主機上刪除了文件，則TSM中仍然保留最后1個版本，但是是INACTIVE的了。verdeleted=2,是說如果主機刪除了文件，則TSM中保留2個inactive的版本
retextra：當版本成為非活動版本以后，指定保留此備份版本的天數。當客戶機存儲更新的備份版本，或客戶機刪除工作站中的文件，然后運行完全增量備份時，文件的備份版本變為非活動。服務器根據保留時間刪除非活動版本，即使非活動版本數超過VEREXISTS或VERDELETED參數容許的數目。缺省值是30天。
此參數就是說當主機上的文件被刪除后，TSM中如果定義了還保留有版本，則此參數指定改版本保留的天數。
retonly：指定已從客戶機文件系統中刪除的文件的上一個備份版本要保留的天數，缺省是60天。
此參數就是說主機上文件被刪除后，TSM中保留的最后一個版本的天數。
以上四個參數一定要記住。否則將釀成大錯。
客戶一般是把文件備份到TSM里面以后，就把文件從主機上刪除掉了。看LOG什么的都正常備份了。
每天對同一個目錄做備份，每天做刪除，年復一年。
然后直到有一天，要恢復數據了，發現以前備份的數據都不在了，為什么？為什么？
因為：verexists=1 verdeleted=0
7、TSM備份調度策略如何規劃？
通過上面的介紹，我們對TSM的策略層面和存儲層面有了一個簡單的理解。基于這個理解，在設計調度的時候可采取正反向兩個方向去推論。
正向：基于業務需求，備份窗口等去設計。比如，考慮到白天業務繁忙，為了減少影響需要將備份放到晚上。備份最少需要3個小時，那就要計算好備份的時間段，避免影響業務。
反向：基于存儲的實際情況。比如備份環境使用了物理磁帶庫，驅動器的個數、是否使用lanfree等因素就要考慮進來，避免備份作業設置不當發生驅動器的爭用。
8、同一節點數據保留不同時間，TSM能否通過指定不同的保留策略來完成？
對于同一節點的數據保留數據的期限不同比如每天備份保留一個月每月備份保留1年每年備份保留10年這樣的保留策略。TSM 要設置并指定不同的管理類不同的節點或者添加排除等，而目前很多其他的備份軟件只需要指定不同的保留策略就可以了。 TSM有沒有這種簡單的做法？
TSM使用兩種方法來解決：
設置不同的節點，節點分屬不同的策略域
只用1個節點，使用多個管理類，再通過dsm.sys文件中的選項來實現
實際上從原理來講，和其他備份軟件的實現方式應該大致相同。
9、TSM存儲介質中存儲池和庫有什么區別呢？
庫在TSM里的物理對應就是機械手
池是個邏輯概念，可以由不同的介質類型構成，比如文件、lto等等。可以通過設備類指定。
存儲池再和副本組中的dest參數關聯。對應到不同的策略域
這樣就形成閉環了。
10、使用TSM備份Oracle，怎么設置通道會比較好？
通道數越多，對數據庫業務影響越大，對數據庫的并發讀性能要求越高，但如果通道數越多而通過單個通道內備份的data file越少、數據量越小，反而會降低備份效率。備份最終是要落入磁帶庫的，對于磁帶機而言，連續且大量的數據寫入效率是最高的。至于怎么平衡，取決于備份管理員對這個系統數據庫和備份的理解了。
下面是ORACLE備份通道與消重效率的心得分享：
不管是哪一款備份軟件，對備份數據備份流程的控制尤其重要，特別是采用消重技術的備份。對備份數據的控制效用將直接影響消重性能。消重技術以變長、定長兩種為例，顧名思義變長是可以根據數據長度動態調整切片長度（如EMC DataDomain）,定長僅僅是以固定長度對數據進行切片。切片完成后，片（piece）的命中率直接決定消重性能。piece的命中率越高，消重越明顯。因此如何控制備份片（backup piece）單一度且相似度成為重點。
我們知道Oracle的Rman腳本里，有一個fileperset參數來控制每一個backup piece里會包含多少個data file。設想一下，如果fileperset越高，那每個backup piece就會包含更多的data file，backup piece的雜糅度就會越高（data file會被混亂隨機的組成一個backup piece，并不是每次都按照同一個順序擬成），那么消重切片后piece的重復率必然低。綜合分析，一個合理的fileperset值將有效提升消重效率，fileperset越小越好，理論為1最好（如果沒有多路復用的情況，一個流會話會占用一個備份設備）。
接下來關注備份通道數，Oracle的備份效率與數據結構類型、數據大小以及備份配置等息息相關。如何合理規劃備份通道數？關于此問題，我們需要了解一個概念------多路復用（multiplexing）。這個功能能夠讓多個oracle channel的備份流寫入一個磁帶機，如rman里分配了四個通道，但備份只有一個磁帶機在跑。對于單個磁帶機來講，連續、大量的數據流具有更高的寫入效率，如果單個backup piece數據量偏小就需要適當提高multiplexing的復用效率：允許x個會話同時寫入該設備（此操作提高數據雜糅度會降低后端消重效率）。對于Oracle而言，如果數據庫性能允許，更多的channel會帶來更高的數據讀取效率，備份速度越快。然而考慮到備份對業務的影響以及并發性能的限制，最佳的通道數需要多次調整嘗試。
除此之外若是oracle的消重備份，如果設置rman讀取datafile時的讀取塊大小以及備份軟件寫數據的塊大小以及設備消重的最小長度呈倍數關系，在消重效率和備份速率上都會有一定提升。
11、TSM備份和恢復在Oracle Rac下的具體操作是怎樣的？兩個節點都有問題的恢復嗎？
TSM for oracle的模塊所起的作用，簡單理解僅僅是提供了備份恢復的通道而已。所以在處理這個問題的時候先不要被tsm迷惑，僅從單純的oracle rman角度去考慮即可。
實踐上，rac環境的備份恢復僅在一個節點做就可以了，操作步驟基本上和單機環境沒什么區別。
唯一需要考慮的一點就是rac環境下兩邊日志是存儲在共享存儲還是兩邊各是個的，要確保備份恢復的動作可以同時獲取兩個節點的歸檔信息，其他就沒啥區別了。
12、TSM備份失敗可能的原因？如何處理？
備份軟件的日志一般是第一手判斷問題的重點。多數成熟的備份軟件都會有詳細的日志來說明相關的錯誤。
其次就是確認備份的環境、網絡、系統狀態、備份服務這些。
很多原因都會導致tsm備份失敗，查找原因需要看日志——
查看一小時以前的所有日志：
query actlog
如查看昨天8點以后的所有日志
query actlog begindate=today-1 begintime=08:00:00
查看日志中有關nc_ora節點的相關信息，可以加上search參數
query actlog search=nc_ora
查看TSM服務器中的日志信息：
query actlog originator=server
數據庫：api的log，tsmserver的log
文件：ba的log，tsmserver的log
RC 106，一般是日志權限的問題，找到需要的日志，加上權限。
RC 12，介質mount不可用，一般是TSM調用帶庫的時候出現問題，查查驅動器和path，看看存儲池的最大可用scratch數值；如果是磁盤，看看磁盤的文件系統權限。
第一次啟動調度的時候，如果調度進程未啟動，可能是因為password生成參數沒設置好，或者沒有手動的登錄一下客戶端。
ANS0102W，語言包的問題導致dsmc登錄不了，將/opt/tivoli/tsm/client/lang/en_US目錄內所有內容，拷貝到/opt/tivoli/tsm/client/ba/bin目錄下試試。
ORA-19554，動態鏈接庫的問題可能大些。
如果日志表述無法直接定位問題，那么需要分析該問題是服務器端還是client端的問題，如果其他備份作業成功完成，那么備份服務器基本判斷可用；之后看存儲池，發起測試備份寫入該存儲池，如果可行則存儲介質基本判斷可用，帶庫路徑驅動器路徑可用；如果是數據庫備份，則嘗試發起文件備份，如果文件備份成功，那么基本判斷是該節點的數據庫備份問題，那么可以嘗試重新執行配置，和檢查配置文件的方式，判斷問題。
13、TSM備份軟件實現數據級容災的實現方式是怎樣的？
數據容災，根本思想是關鍵的業務數據保留多份備份（本地和遠程）。 支持業務的基礎架構還有許多其他東東，物理機/虛擬機，虛擬機管理系統，存儲系統，實際的軟件/中間件/數據庫等。這些都好恢復，數據丟了就歇菜了！ 要想提高可用性，實現容災，提高RPO, RTO,也可以采用應用層方案，多活中心等，應用架構設計就考慮軟硬件故障，site故障等情形，但代價很高，更多的軟硬件，系統架構，運維更復雜等等，一般的企業不現實。 所以數據級容災就是以盡量小的代價獲得較高的收益！
TSM 大概可以有幾種方式：
云備份池：
最新的7.1.6支持 復制數據到云備份池（openstack, amazon, clearsafe), 復制到云池的數據在線去重/壓縮。
磁帶拷貝池：
傳統方式，主池定期做備份到拷貝池(一般每天），拷貝池磁帶check out后運往本地或遠程災備中心。 相似的還可以采用export to tape, generate backupset to tape.
企業多站點，多個TSM Server的時候：
TSM server之間可以repl node/protect stg（6.3+以上server)，export to server將數據存在別的server中一份。
RPO/RTO 跟你使用的備份方式密切相關，比如采用磁帶拷貝池，晚上對主池備份一次，運到災備中心，RPO只能是恢復業務到一天前狀態。那我們采用云備份池/TSM server之間可以repl node/protect stg，設定每天更頻繁的數據復制，則RPO是以小時計，整個業務系統可以恢復到幾個小時前的狀態。
RTO 則跟實際恢復數據時間（磁帶恢復速度）， 你的網絡帶寬（repl node方式，云備份池），從災備中心運回磁帶的速度，恢復其他基礎架構的時間密切相關。
14、虛擬帶庫里有這樣一盤磁帶，在TSM下看是空的scratch狀態，在EMC控制臺下看到是滿的？
1.查看帶庫日志和備份軟件相關日志信息；
2.TSM備份配置參數：
如果collocation的參數設置不是no。則可能的參數值包括：filespace，node，group。
如果設置為filespace，則磁帶選擇的順序是：
1． 優先選擇已經備份同一文件空間數據的磁帶；
2． 已經定義的空白磁帶；
3． 定義為scratch的空白磁帶；
4． 包含同一節點數據的已經使用過的磁帶；
5． 空間最大的一盤已經使用過的磁帶；
如果設置為node，則磁帶的選擇順序是：
1． 包含同一節點數據的已經使用過的磁帶；
2． 已經定義的空白磁帶；
3． 定義為scratch的空白磁帶；
4． 空間最大的一盤已經使用過的磁帶；
如果設置為group，則磁帶的選擇順序是：
1． 優先選擇已經包含來自客戶端所屬的collocation group的備份數據的磁帶；
2． 已經定義的空白磁帶；
3． 定義為scratch 的空白磁帶；
4． 空間最大的一盤已經是使用過的磁帶。
面對上述例子中情況，用戶可以考慮下列方法來跳過需要等待的60分鐘。
在checkout命令執行完后，修改磁帶A0000的access屬性為unavailable。命令如下：
update volume A0000 access=unavailable
15、備份VCener的解決方案
通過VMware VADP接口，將數據映射并和TSM API（TSM for VE）結合后，直接集中備份到備份設備中存放。
采用持續增量備份，就是TSM的永久增量備份技術，可以以最合理的方式減少備份窗口，冗余數據和備份設備介質的資源使用率。
只有第一次是全備份（去掉了VM的空塊空間）。
后續備份，全部采用持續增量備份，自動啟動VMware的CBT（changed Block Tracking)功能，并跟蹤塊的變化進行僅增量備份。
16、TSM 怎樣實現歸檔SQLServer 2012 AlwaysON環境的數據庫的備份？
SQL Server2012中新增的AlwaysOn是一個新增高可用性解決方案。在AlwaysOn之前，SQL Server已經有的高可用性和數據恢復方案,比如數據庫鏡像，日志傳送和故障轉移集群.都有其自身的局限性。而AlwaysOn作為微軟新推出的解決方案，提取了數據庫鏡像和故障轉移集群的優點。
因為always on 環境下，數據文件都到了 cluster節點對應的存儲池中。
現在我想到的另一個方法就是單獨通過SQL備份出文件，然后文件 歸檔到TSM
上面這種備份方式需要測試數據的完整性，確認數據是否可用。
17、如何保證TSM服務器端與客戶端的正常運行？
1，注意定期對tsm服務器和客戶端的巡檢，及時發現問題并處理。
2，定期檢查tsm備份是否成功，如果備份失敗查清原因并處理。
3，定期做好備份數據的恢復演練，保證tsm備份成功的數據是可用的。
4，配合自動化啟停腳本完成TSM系統的監控。
18、如何做到TSM系統的自動運維？
1，可以考慮使用crontab或調度完成備份，配合腳本完成日常檢查，比如郵件等功能，可以結合監控軟件如bmc或zabbix完成物理硬件和應用可用性監控，當然可以配合商業產品完成漂亮的圖表等查詢功能。
2，把TSM的運維做好的話，每天的人工巡檢是一部分工作之外，可以考慮投入一部分資金基于TSM平臺進行一些開發，因為TSM有這樣的接口，比如調度執行結果，尤其是TSM調用腳本執行的結果，日志在本地生成，可以考慮通過Agent采集的方式把日志收集上來；比如數據量監測，每天的數據量都維持在一個平穩的數值，如果某一天數據量上來了，應該關注一下。應該有一些工作在做這方面的定制化。
19、為啥TSM對調度要“暫掛”
TSM如果對調度進行“立即運行”的時候，它會暫掛個好幾分鐘，為什么要這么久呢？沒什么設計理由讓它等這么久吧？
是從OC/AC 上提交的吧，這個從用戶角度是比較搞笑哈 ：）
實際TSM Scheduler的決定運行某個schedule的時候，是有一定的隨機性的，比如我們設定schedule的時候，大部分要設定一個啟動時間范圍，Server在這個時間范圍內啟動schedule就可以了。
從Server的角度考慮，在某個時刻，server可能面臨各種操作，比如客戶備份，恢復數據，expire inv, migration， reclamation. 還有一些內部damon做其他檢查，比如后臺線程做tsm db index rerog等等， 如果在一個時間段設定了很多schedule, 先啟動那個，后啟動那個呢？ 為了避免沖突，server就盡量在符合設定的情況下， 按自己的節奏來啟動這些活動，就是有一定的隨機性。
20、TSM 經常會遇到物理帶庫里的部分或個別volume不能自動回收如何定位問題？
在tsm的使用過程中，經常會遇到部分或個別volume不能自動回收，比如說保留策略為一周，時常能夠發現個別好幾個月前的磁帶還在帶庫中，沒有被回收。其中里邊的數據也均是老數據。1 ）遇到類似問題，應該如何操作和避免呢？ 2）有沒有什么好的手段或機制做檢查，發生這個問題的原因又是什么，如何定位問題 ？
想回收的話，檢查tape pool的回收閥值設置， 查看每個卷的可回收空間 pct_reclaim，
select volume_name,status,pct_reclaim from volumes where stgpool_name=‘TAPE’ and pct_reclaim >= 0.0
or
http://www.thobias.org/tsm/sql/#toc120
然后可以降低RECLaim 的閥值，讓server回收這些磁帶。
update stg TAPE RECLAIMPRocess=4
RECLaim STGpool TAPE THreshold=10
或者用 命令 Move data vol_name 將這些磁帶里數據挪到別地，然后老帶子在REUsedelay天數過后就可以利用了。
檢查tape pool的回收閥值設置，mascr 設置以及 REUsedelay 的設置。 q content 查看是那些節點的數據，是否是新數據還存在這些帶子里？ 如果都是老數據沒有被expire inv過期，這個沒有詳細信息不好說，根據數據類型不同：歸檔數據，備份數據？ 先查查copygroup的各項設置吧。
總結
以上是生活随笔為你收集整理的二十个不可不知的 TSM 知识点的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： centos8安装NVIDIA显卡驱动，
- 下一篇： 服务网格——后 Kubernetes 时