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