1. 你遇到過哪些數(shù)據(jù)備份在關(guān)鍵時刻無法恢復(fù)的情況？
@hufeng719 某制造集團(tuán) 系統(tǒng)工程師：
目前備份只有DB2數(shù)據(jù)庫用到過，沒有遇到過硬件無法啟動、數(shù)據(jù)庫無法啟動等大的故障，只是誤刪除表數(shù)據(jù)，誤刪除某個或幾個表。這個時候數(shù)據(jù)庫還能運行，只是丟失部分?jǐn)?shù)據(jù)，直接從備份中還原即可。
SQLServer數(shù)據(jù)庫只做過測試，通過數(shù)據(jù)庫備份和事物日志備份能夠在新機器上還原到事物日志最后備份的時間點數(shù)據(jù)庫狀態(tài)。
Oracle數(shù)據(jù)庫RMAN恢復(fù)未做過測試，只是用exp、imp做過導(dǎo)出導(dǎo)入的還原操作，這種肯定會丟失部分?jǐn)?shù)據(jù)。
Mysql數(shù)據(jù)庫也是用sqldump備份 source還原過。
所以，Mysql和Oracle如何能夠還原到故障點發(fā)生時的數(shù)據(jù)庫狀態(tài)，還需各位大俠一起分享經(jīng)驗。
@Jerry 某保險公司 系統(tǒng)架構(gòu)師：
此前在運營商闖蕩的時候，遇到過一起很典型的掉鏈子例子：
運營商的好多客戶數(shù)據(jù)都是需要長期保存的，而且不能丟，遇到重大刑偵案件的時候往往要調(diào)取這些數(shù)據(jù)協(xié)助調(diào)查，如果提供不出來，會對公司當(dāng)年的考核影響很大。有一次呢，遇到了一個大案，上頭發(fā)文讓協(xié)助調(diào)查，需要恢復(fù)指定的通話記錄和部分內(nèi)容，在系統(tǒng)里很快就查到當(dāng)年數(shù)據(jù)的所在業(yè)務(wù)系統(tǒng)，定位到了數(shù)據(jù)所在的服務(wù)器，隨后確定了數(shù)據(jù)的時間，接著就讓備份管理員開始著手恢復(fù)數(shù)據(jù)，檢查恢復(fù)環(huán)境，檢查數(shù)據(jù)備份狀態(tài)，確認(rèn)數(shù)據(jù)時間版本，一切OK，開始恢復(fù)，恢復(fù)完了都傻眼了……恢復(fù)了一堆數(shù)據(jù)，里面壓根沒有需要的數(shù)據(jù)。
后來查證，原來因為系統(tǒng)的某個需求變更，一部分業(yè)務(wù)數(shù)據(jù)被獨立出來，存取路徑變更了，變更也沒告知備份管理員，同時這部分業(yè)務(wù)數(shù)據(jù)體量又很小，整個系統(tǒng)數(shù)據(jù)備份的體量遠(yuǎn)大于這部分?jǐn)?shù)據(jù)，備份軟件的監(jiān)控上備份任務(wù)詳情里無論從備份數(shù)據(jù)量、備份時間都在正常范圍內(nèi)。更不幸的是，這個系統(tǒng)從來都沒被抽到進(jìn)行數(shù)據(jù)恢復(fù)演練……因此獨立出來的數(shù)據(jù)，這幾年都沒備份……
實踐是檢驗真理的唯一標(biāo)準(zhǔn)，對于備份恢復(fù)也是如此。智者千慮必有一失，作為數(shù)據(jù)保護(hù)的最后一道防線，其核心本質(zhì)就是可靠、完整、安全。不管是思路、策略還是配置上的疏漏，在演練中均可暴露出來，讓管理員及時查漏補缺。
2. 備份系統(tǒng)如何實現(xiàn)快速的備份和恢復(fù)？
【問題描述】現(xiàn)有的環(huán)境是NBU+虛擬帶庫，整體架構(gòu)比較老式。需求是：想實現(xiàn)對一些近60TB的零散的大量文件進(jìn)行備份，而且經(jīng)常需要進(jìn)行數(shù)據(jù)庫的備份恢復(fù)。是否有新的備份體系，可以實現(xiàn)無需通過恢復(fù)的方式，就可以對備份的數(shù)據(jù)進(jìn)行讀取和抽取。
@某集團(tuán) 系統(tǒng)架構(gòu)師：
1、備份：
NBU和Commvault都能實現(xiàn)備份快，但實現(xiàn)原理不同。
NBU是通過在文件系統(tǒng)中使用tracking file來做文件級別的備份，因此無法避免首次備份慢的問題，后續(xù)還是看變化情況，如果變化量不大，是OK的，除此之外，還需要定期進(jìn)行force rescan，否則會出問題。以前7.0時代曾經(jīng)用過flash backup技術(shù)，但需要有專門的快照卷，而且備份大小是卷的大小，后面此技術(shù)被前面這種基于tracking file的accelerator技術(shù)取代。
Commvault是通過塊級別的備份，首次全備份和后續(xù)增量備份可以很快，結(jié)合合成全備份可以實現(xiàn)永久增量備份。塊級備份對生產(chǎn)影響小，不用擔(dān)心掃描和備份海量文件對生產(chǎn)的影響。Commvault還可以在同一個任務(wù)里實現(xiàn)備份和歸檔，可選擇留或者不留存根文件，有存根文件就可以實現(xiàn)用戶無感知的訪問已歸檔走的文件。
2、恢復(fù)：
NBU基于tracking file的accelerator只能用于備份加速，遇到還原的時候，還得實打?qū)嵉幕謴?fù)，相當(dāng)于首次備份的速度。
Commvault的還原可以從塊級別備份中還原單個文件，還原整個卷到源卷、不同卷和異機均可，規(guī)避了還原小文件慢的問題，還可以按需掛載成一個路徑，支持掛載到原機和異機，比較靈活。
@Jerry 某保險公司 系統(tǒng)架構(gòu)師：
60TB的文件不知道是小量的零碎文件還是大規(guī)格的數(shù)據(jù)文件，如果是海量小文件的問題，只能想辦法改善備份慢的問題，能夠完美解決海量文件備份效率的方案，成本都不低，入不敷出。
利用塊級別備份備份海量文件，雖然可以解決備份效率慢問題，但是恢復(fù)的時候無法精確恢復(fù)單個文件，因此在備份的時候需要更多規(guī)劃，包括數(shù)據(jù)存取，數(shù)據(jù)結(jié)構(gòu)等。往往這更多規(guī)劃，難以實施，海量小文件的形成必然是長時間的積累，為了備份恢復(fù)去大刀闊斧的改造，很多企業(yè)都下不了狠手。
海量小文件的問題，更多的可以從兩個方面入手，第一個是優(yōu)化海量小文件的文件結(jié)構(gòu)，想辦法把小文件聚合成大文件，提高備份恢復(fù)效率，減少文件掃描的時間成本，常見的做法就是進(jìn)行打包壓縮。第二個就是改變海量小文件的存儲方式，海量小文件備份恢復(fù)慢，絕大部分是對文件的掃描、備份時因為數(shù)量龐大導(dǎo)致open files、close files的次數(shù)特別多，如果不是以小文件方式直接備份恢復(fù)文件、直接從系統(tǒng)底層直接抽取數(shù)據(jù)進(jìn)行備份恢復(fù)……在這點上不少企業(yè)使用了對象存儲，需要注意的是對象存儲的備份接口引擎，可能需要定制化。
數(shù)據(jù)庫的場景，可以采用CDM技術(shù)進(jìn)行，CDM備份只要條件滿足，可以直接抽取備份副本直接拉起數(shù)據(jù)庫，這點在很多場景比傳統(tǒng)恢復(fù)方便，但同時你也要接受這種方案的高成本和高環(huán)境要求。
直接從備份存儲拉起數(shù)據(jù)，這是CDM類產(chǎn)品擅長的，傳統(tǒng)備份恢復(fù)系統(tǒng)起初并不是遵循瞬時恢復(fù)而設(shè)計，而是考慮長期數(shù)據(jù)保護(hù)，兩者的出發(fā)點就已經(jīng)不一樣。對于核心數(shù)據(jù)，恢復(fù)要求較高的，建議采用CDM方案，基本都能做到瞬時恢復(fù)直接拉起，但其成本與要求較高，還得根據(jù)實際情況來確定。
3. 對于長期數(shù)據(jù)保留，是采用大容量去重磁盤設(shè)備好？還是磁帶庫好？
@潘延晟 系統(tǒng)工程師：
因為有過教訓(xùn)。所以對于數(shù)據(jù)的備份。我一向秉承著在我資金允許的范圍內(nèi)盡可能多的備份。短期數(shù)據(jù)備份用磁盤。長久保存用磁帶。磁帶要定期更換。
另外還有一點就是你能承受數(shù)據(jù)丟失的程度和你備份的投入的比例。如果數(shù)據(jù)不算太重要。那么有個基本備份就好。隨著數(shù)據(jù)越來越重要。這部分備份的投入也要不斷的增加。方式也要多種多樣。
@Jerry 某保險公司 系統(tǒng)架構(gòu)師：
長期保留數(shù)據(jù)，采用大容量去重磁盤設(shè)備和磁帶庫均可，主要有幾方面需求因素影響最終選擇：
1，是否需要離線？異地保存？
如果有這方面的要求，基本只有磁帶庫選擇。
2，綜合能耗成本考慮
采用大容量去重磁盤設(shè)備的綜合能耗成本基本遠(yuǎn)大于磁帶庫的能耗，另外需要注意的是磁盤的故障率比磁帶高很多，磁帶如果保存條件良好可以保存十年之久，而磁盤很難。如果沒有這方面考慮，兩者都是不錯的選擇。
3，管理難度
一般來說磁盤設(shè)備的管理難度小于磁帶庫，磁帶庫的磁帶機、機械臂都屬于高精密儀器，高頻度使用耗損還是很嚴(yán)重的，出問題了進(jìn)行更換后往往還涉及一系列的配置問題。磁盤設(shè)備不管是基于虛擬磁帶庫還是高級文件系統(tǒng)，在這方面的配置都比磁帶庫方便的多。
4，恢復(fù)效率
這一部分兩種存儲介質(zhì)的區(qū)別并不是很大，多個磁帶機并行也能達(dá)到磁盤控制器相近的速度。
@luo_x_f 某軟件集團(tuán) 系統(tǒng)架構(gòu)師：
對于長期數(shù)據(jù)保留，首先看數(shù)據(jù)類型（是結(jié)構(gòu)化數(shù)據(jù)還是非結(jié)構(gòu)化數(shù)據(jù)），其次看其數(shù)據(jù)的使用頻率（經(jīng)常使用還是偶爾使用），最后就是你的投入預(yù)算。
對于大容量磁盤，一般都是做虛擬帶庫。需要考慮磁盤的電子元器件老化（硬盤使用壽命一般不超過8年），同時只要運行就需要用電，后續(xù)的成本投入會比較高。
對于磁帶庫需要考慮備份速度和備份時間窗口，電費應(yīng)該能省不少。磁帶放置在電子防潮柜，恒溫恒濕環(huán)境理論是30年，一般是10年進(jìn)行換代（存取速度、介質(zhì)容量、驅(qū)動器都有幾倍提升）。如果數(shù)據(jù)量比較小，那可以直接買個較大容量的磁帶庫，所用磁帶直接放到磁帶庫中。如果數(shù)據(jù)量大或者是需要異地存放，那就要考慮電子防潮柜建設(shè)及維護(hù)。另外，如果是保存非結(jié)構(gòu)化數(shù)據(jù)，磁帶庫的LTFS技術(shù)配合磁帶廠商的軟件可以把磁帶庫直接當(dāng)成NAS使用。
備份數(shù)據(jù)存儲的選擇需要諸多方面的權(quán)衡，以數(shù)據(jù)為重？以成本為重？還是以效率為重？一般對于數(shù)據(jù)長期保留需求，建議以磁帶為主，可以輔助其他方式存儲作為備用介質(zhì)。磁帶，無論是出入庫異地保存，備份恢復(fù)速度，還是綜合使用成本，相較而言合適得多。
4. 如何增加海量小文件的非結(jié)構(gòu)化數(shù)據(jù)備份的速度？
@Jerry 某保險公司 系統(tǒng)架構(gòu)師：
海量小文件的問題，現(xiàn)在一直沒有根本性解決，能夠完美解決海量文件備份效率的方案，成本都不低，入不敷出……
海量小文件的問題，可以從兩個方面入手，第一個是優(yōu)化海量小文件的文件結(jié)構(gòu)，想辦法把小文件聚合成大文件，提高備份恢復(fù)效率，減少文件掃描的時間成本，常見的做法就是進(jìn)行打包壓縮。第二個就是改變海量小文件的存儲方式，海量小文件備份恢復(fù)慢，絕大部分是對文件的掃描、備份時因為數(shù)量龐大導(dǎo)致open files、close files的次數(shù)特別多，如果不是以小文件方式直接備份恢復(fù)文件、直接從系統(tǒng)底層直接抽取數(shù)據(jù)進(jìn)行備份恢復(fù)……在這點上不少企業(yè)使用了對象存儲，需要注意的是對象存儲的備份接口引擎，可能需要定制化。
海量非結(jié)構(gòu)化小文件備份恢復(fù)問題，一直是容災(zāi)上的難題。在海量非結(jié)構(gòu)化文件的備份恢復(fù)過程中，非結(jié)構(gòu)化文件的掃描將消耗大量時間成本，碎片性質(zhì)更一步降低了系統(tǒng)效率。這是文件特征，也是文件結(jié)構(gòu)類型決定的，即使采用存儲級快照技術(shù)解決了備份效率問題，恢復(fù)時精度又得不到保證，投入和產(chǎn)出比低，效果也不盡如人意。因此，對于此類問題建議折中處理，減少海量、小文件的產(chǎn)生，以少聚多，以小變大，將海量、小的問題轉(zhuǎn)變?yōu)檫m量、適中的方向來解決。
5. 如何評估備份策略？
@Jerry 某保險公司 系統(tǒng)架構(gòu)師：
對于備份策略的制定，一是保持高效，盡量在最短的時間完成備份恢復(fù)，為其他任務(wù)節(jié)省時間窗口；二是盡量降低網(wǎng)間壓力，降低備份恢復(fù)對系統(tǒng)的壓力……
舉個例子，簡化下環(huán)境因素，比如影像服務(wù)器上的保單影像件，數(shù)據(jù)量約500GB，千兆以太網(wǎng)絡(luò)，如何評估備份？
首先從高效方面考慮，影像件通常是碎片文件，不滿足集中備份的數(shù)據(jù)特征，因此就需要評估影像件是否接受壓縮打包之類的處理，將碎片文件聚合成大文件。壓縮打包之后對精確恢復(fù)又增加了難度，最小的恢復(fù)單位變成了一個壓縮包，所以平衡備份高效性和恢復(fù)難易度就成了一個平衡的博弈；對于網(wǎng)絡(luò)壓力來說，若是500GB的碎片文件，備份速度和效率不會很大，但耗時特長，影像服務(wù)器壓力不高時可接受；若是多個壓縮包匯集的500GB文件，那備份速度明顯增加，可能對影像服務(wù)器的網(wǎng)絡(luò)負(fù)載構(gòu)成一定影響，這個時候就需要考慮是否增加agent去分擔(dān)影像服務(wù)器的壓力了……
當(dāng)然，影像件的備份需要考慮的遠(yuǎn)不止這些，影像件的文件類型也是要重點考慮的，若是把這些都帶入這個問題，那就無比麻煩了…
備份策略的優(yōu)化需要長期的經(jīng)驗積累，同時也需要根據(jù)實際情況因地制宜。
