我們要講述的就是某省級體彩中心下轄投注站數據遺失及補救的案例，該投注站由於數據遺失對於日常業務產生了很大的影響，迫切需要一套解決方案。彩票的業務模式是將散落的數據“集中”到省級中心的數據庫中，並上傳國家級數據備份中心，這是一個典型異地、異構數據備份系統。主要特點體現在：
我們講述故事中，所幸的是丟的僅是個別“羊”只——個別投注站上傳數據丟失、利用較窄帶寬傳輸數據“失真”——局部號段錯位、丟失，等等，好在還沒有丟失“羊群”，但這個警鐘已敲響，彩票在投注站打印出來就形成了合同關系，如中獎數據丟失還需給付獎金造成的損失都是由省體彩中心“買單”的。
究其上述某省級體彩中心數據丟失災難的原因是因為存在手工上傳數據時低帶寬環境的信號延時、不同數據庫類型間轉換數據等潛在的漏洞，這些漏洞更需“補牢”，而且這次“補牢”需要一個徹底的解決方案——實現數據庫異構備份：各投注站與省級中心間、各省級中心與國家中心間都要建立跨平台的“N+1”模式容災。 縱觀各路數據庫備份產品中，能夠實現異構備份者已是鳳毛麟角。再論性能優劣、技術前瞻性、客戶口碑，IBM TSM(Tivoli Storage Manager)備份管理工具實為最佳選擇。
IBM TSM全面支持主流平台和主流廠商的數據庫系統，包括Oracle、DB2、Informix、SQL Server、Sybase等。對於異構數據庫(以Oracle為例)，使用TSM的數據庫保護模塊TSM for Database/Oracle能夠很好的對其進行全面的保護——使用數據庫的備份接口，以透明化的方式提供數據庫管理員一種進行數據備份的方法。基本原理是：
仍以Oracle為例，備份Oracle數據庫需要TSM for Database/Oracle，它利用ORACLE數據庫提供的備份接口RMAN來對數據庫進行備份。Oracle備份工具RMAN能夠生成需要備份的數據文件，並能夠保證數據庫的一致性，所有的熱備和邏輯備份都通過Oracle RMAN唯一接口進行。Tivoli可以利用這些工具實現對Oracle數據庫的各種對象進行在線/離線備份，另外通過RMAN增量備份的機制，TSM可以實現對Oracle數據庫的增量備份。而在被備份數據的輸出上采用了和TSM結合的方式，TSM就是一個雙向管道，一方面利用數據庫的API和數據庫備份軟件連接，另一方面利用TSM的API和TSM連接，將數據庫備份軟件的輸出傳送到TSM管理的備份介質中。在Oracle中，直接設置了和TSM的連接，只需要在Oracle的相關配置中設置TSM服務器的名稱和IP地址即可。為了減少DB主機壓力和減少備份時間，對於Oracle數據庫，同時能夠提供數據庫的增量備份，僅僅備份包括自從上次備份過程以後被改變過的data files的data blocks。這些數據可以和上面談到的文件備份分開，存在不同的存儲池中，通過不同的存儲策略來進行管理。
恢復同樣可以根據發生故障的種類，在數據庫管理員的判斷下，靈活的針對數據庫的任意一個部件進行。如果業務數據量較大，建議對數據庫的全備份每天或每兩天做一次，而每隔一段時間備份數據量較小的Transaction Log。當發生數據損壞或丟失時，先恢復最近備份的數據庫和Transaction Log，再用Transaction Log進行Forward Recovery，從而將數據庫恢復到最近一次備份Transaction Log時的狀態。在這種備份策略下，最壞情況會丟失一段時間的數據。通過將備份Transaction Log的時間間隔減小，例如減小到每小時備份一次(這一備份時間間隔應根據Log數據量和網絡帶寬情況制定)，能夠最大限度地減少數據丟失;對於 master database的數據，由於數據量不會太大，而且數據變化相對較小，所以建議每周做一次全備份。
綜上所述，使用TSM能夠靈活的對用戶的異構數據庫自動化的定時進行備份的工作，已達到容災的效果——應用到上述省級彩票中心的案例中，在全省方位內沒有對終端數據庫進行改造的前提下，可以將各投注站或縣市級體彩中心數據“整齊劃一”，也徹底消滅了數據丟失!而且與主要競爭對手的備份方案各方面對比，詳見下表，均有優勢。通過上述技術性能的闡述，TSM作為當今面臨數據爆炸式增長環境中，企業成功管理和控制 “信息浪潮”的利器，應該被人信服的。唯一有所忌憚的是先期成本的投入，誠然TSM這樣優秀產品是有代價的。但“補牢”後，不僅不會再丟羊，而且羊兒會更強壯!——有助於提高IT操作的效率， 幫助削減與存儲管理相關的成本，特別是數據災難的“沉沒成本”。
