談到備份，需要記住兩件事情：“如果你的數(shù)據(jù)沒有保存在至少兩個地方，那么它就等同于不存在；而沒有經(jīng)過測試的備份數(shù)據(jù)恢復(fù)進程，也不能稱之為備份。

沒有什么會像自然災(zāi)難一樣測試你的進程。

筆者正好要解決這樣一個問題，請看。

光纖網(wǎng)絡(luò)

要想談?wù)搨浞�，我們首先得了解我們需要備份什么以及為什么要對其進行備份。

遇到難題的客戶有兩個數(shù)據(jù)中心，一個字Edmonton，另一個字Calgary。每個站點都有光纖--理論上，速度可達100M，但是速度被限制了以便符合ISP的協(xié)議。

如果我們兩個地方的累積使用保持著XMbps之下，那我們就可以享有所有帶寬。不封底，不會出現(xiàn)巨額賬單。這是易于管理的可預(yù)測的成本。

更重要的是，為了不出現(xiàn)意外，所以不為網(wǎng)絡(luò)設(shè)置上限需要一個單獨的命令。

每個地方都保留有當?shù)赜脩舻拇罅渴褂眯畔ⅰ＿@些信息可以解決硬件故障，但在公司外部就不能復(fù)制了。

我們把帶寬稍微調(diào)高了一點，來處理內(nèi)向數(shù)據(jù)；我們無法支付云存儲的費用，即便我們是把數(shù)據(jù)發(fā)送到自有數(shù)據(jù)中心之一。

我們部署這個基礎(chǔ)設(shè)施是為了滿足當?shù)氐男枨螅�似乎不托管面向公眾的網(wǎng)站，不在自己的基礎(chǔ)架構(gòu)上托管IT服務(wù)就是一件很傻的事情。這兩個地方都有私有云，。雖然不是Amazon，但是夠用了。

復(fù)制

公共網(wǎng)站的數(shù)據(jù)庫都不是為了實時復(fù)制而創(chuàng)建，因為這需要重寫代碼。出于多方面的考慮，目前還不可行。

所以，備份成為了每個MySQL服務(wù)器上的必須要進行的計劃性任務(wù)，這樣才能創(chuàng)建常規(guī)的數(shù)據(jù)庫轉(zhuǎn)儲，壓縮，加密，然后再發(fā)往我們的文件服務(wù)器。

與此同時，每個Web服務(wù)器的代碼庫都執(zhí)行著同樣的備份。這些有問題的文件服務(wù)器是運行于分布式文件系統(tǒng)復(fù)制（DFSR）上的Windows系統(tǒng)，DFSR可以很好地復(fù)制備份。

每個站點的集群中都有相同的文件服務(wù)器，他們都包含文件副本。這些文件會通過WAN發(fā)送到其他站點。從這一點說，我覺得我們可以很好地應(yīng)對硬件故障。

總部的備份服務(wù)器運行的是非常古老的Retrospectt版本，它創(chuàng)建帶有版本號的備份，以防止惡意軟件或其他可能刪除DFSR共享中備份的事故。所以，每一邊的備份目錄中的數(shù)據(jù)會自動復(fù)制到兩個系統(tǒng)中。

潛在的個人可識別信息被加密了--包括數(shù)據(jù)庫和rar壓縮包中的信息，都不會離開公司的控制。

這其中，肯定存在更好的方案，但是由于沒有這方面的預(yù)算，所以一般公司都主張到此為止。

焦灼之夜

對于我們的很多系統(tǒng)而言，我們不僅僅是測試備份--在常規(guī)基礎(chǔ)上從這些備份做數(shù)據(jù)恢復(fù)是一項自動進程。和優(yōu)秀的系統(tǒng)管理人員一樣，我們維護的是一個測試實驗室，然后每天早上用前一晚的數(shù)據(jù)做重新填充。

幾乎所有的重要系統(tǒng)都具備這類自動恢復(fù)序列裝置，所以我們很少去想這方面的事情。

你會注意到，重要系統(tǒng)都具備自動化的恢復(fù)進程。以前這些網(wǎng)站沒有被當作是很重要的東西。

如果我們出現(xiàn)嚴重的斷電或災(zāi)難，那么這些系統(tǒng)就會崩潰。我們擁有數(shù)據(jù)庫和網(wǎng)站文件，所以手動恢復(fù)應(yīng)該只是幾分鐘的事情。

文件和數(shù)據(jù)庫都在虛擬機上，如果你沒有虛擬機復(fù)制品，那么就得重新建一個。

Trevor，忘記把虛擬機模板放到備份目錄中。城市發(fā)生洪災(zāi)了，服務(wù)器癱瘓了，而我雖然有大把的rar壓縮包，卻沒法恢復(fù)到他那兒去。

在我們被迫放棄Calgary的數(shù)據(jù)中心之前，我從虛擬服務(wù)器那里啟動了虛擬機下載，準備下到備份目錄中去，希望電力系統(tǒng)能維持足夠長的時間，使虛擬機通過WAN得到復(fù)制。

我取消了光纖鏈接的上限，全速復(fù)制，但無濟于事。時間不夠。

無法預(yù)料的行為

搭建一個虛擬機僅需幾分鐘，注入數(shù)據(jù)庫，上傳文件。睡眼惺忪，疲憊不堪的我至少用了一個小時搞清楚網(wǎng)站不能加載的原因--在恢復(fù)MySQL數(shù)據(jù)庫后，我廣濟抹掉MySQL服務(wù)器上的優(yōu)先權(quán)。

解決完這個問題，網(wǎng)站可以加載了……但還是有問題。大約75%的PHP沒有被解析。在綜合配置文件進行分析后，我意識到是PHP的版本問題，出現(xiàn)問題的版本帶有最新的CentOS，它不支持 短標簽。這些應(yīng)用里的所有代碼都是用這類短標簽寫的，所以，我得把php.ini的值改一改。

問題解決！網(wǎng)站可以正常加載，我們再次上線。故障時間：兩小時多一點。

雖然問題解決，但還不能松口氣。網(wǎng)站提交的郵件信息不成功。找了一圈，對Sendmail操作做了修改后，調(diào)整了它處理主機名稱的方式，才解決這個問題。

如果主機名稱不對，那么當你設(shè)置把郵件發(fā)到互聯(lián)網(wǎng)前先轉(zhuǎn)發(fā)郵件到內(nèi)部處理服務(wù)器時，就會出現(xiàn)問題。Sendmail可能會轉(zhuǎn)發(fā)給某些人，但不是全部。

更不用說，如果操作上有這種漏洞，我們得到消息的時間就要晚一天。那么我們總的恢復(fù)時間就要超過一天了。

優(yōu)秀計劃

主要的操作癱瘓兩小時已經(jīng)是一件糟糕的事情，如果要花上一天才能修復(fù)所有漏洞，著實是糟糕透頂。我已經(jīng)喪失了次級服務(wù)器上的主服務(wù)器和主操作系統(tǒng)，不斷查找問題，用手機網(wǎng)絡(luò)連接系統(tǒng)，終于讓系統(tǒng)起死回生。

我已經(jīng)花了幾年的時間來搗鼓這個刀槍不入的備份系統(tǒng)，但是卻不能弄個詳細的恢復(fù)計劃。

有預(yù)算的公司不用擔(dān)心創(chuàng)建備份基礎(chǔ)設(shè)施的問題。我們有云備份和恢復(fù)軟件供應(yīng)商，如Asigra。

設(shè)備供應(yīng)商，如Unitrends，甚至是數(shù)據(jù)生命周期公司，如Iron Mountain，都能提供備份。可以毫不費力地把你的數(shù)據(jù)保存到一個以上的地方。

這始終都是指測試你的數(shù)據(jù)恢復(fù)過程。所以應(yīng)該多加留意。