對(duì)備份，只是希望在進(jìn)入正式話題之前，允許給一些小提示。
 
● 在備份上不要拖延，做備份其實(shí)并不難。
 
● 做事不要追求完美，而要追求可恢復(fù)。

● 至少對(duì)于可接受的數(shù)據(jù)損失、可接受的宕機(jī)時(shí)間、數(shù)據(jù)持續(xù)策略以及安全需求要形成文檔。

● 對(duì)恢復(fù)過(guò)程要進(jìn)行練習(xí)并形成文檔，恢復(fù)比備份要重要得多!

● 對(duì)于備份作業(yè)成功與否，要進(jìn)行外部驗(yàn)證，不要依賴于作業(yè)自身對(duì)你的提示。
 
下面，讓我們將繁文縟節(jié)的形式拋在一邊，看看怎么用復(fù)制從服務(wù)器做備份。

首先，*顯然的事情，是將從服務(wù)器自身作為備份。不幸的是，這并非一個(gè)真正的備份。在發(fā)生問(wèn)題時(shí)，如丟失了服務(wù)器或其一部分、惡意攻擊造成的數(shù)據(jù)破壞、偶然的DROPTABLE，真正的備份能夠挽回?fù)p失，而復(fù)制從服務(wù)器對(duì)于上述后兩個(gè)問(wèn)題所造成的數(shù)據(jù)損失，卻是無(wú)能為力的，因?yàn)樗皇呛眯牡貙?shù)據(jù)變化復(fù)制了過(guò)來(lái)，從而將數(shù)據(jù)的破壞或損失也一并復(fù)制了過(guò)來(lái)。

所以，怎么做真正的備份呢?假如只有一臺(tái)復(fù)制從服務(wù)器，而且這臺(tái)服務(wù)器也有多余的空間做cron作業(yè)等，則在不用數(shù)據(jù)庫(kù)服務(wù)器的時(shí)候，將其停掉，然后備份其數(shù)據(jù)。對(duì)于MYSQL:在 MYSQL進(jìn)程運(yùn)行的時(shí)候，不要復(fù)制IINNODB的文件，這樣是無(wú)法復(fù)制的。如果能夠停掉MYSQL，然后將其數(shù)據(jù)移走，則對(duì)于大多數(shù)情況，都是*安全的。

如果不想停止服務(wù)器，還有一個(gè)選擇，就是Ktrabackup，一個(gè)免費(fèi)和開(kāi)源的非阻塞備份程序，用于備份INNODB和KTRADBE的表。假如有 MYISAM表，則在復(fù)制時(shí)會(huì)進(jìn)行鎖定。Xtrabackup基于與INNODBI的熱備工具同樣的原理，但 XTRADB開(kāi)源，且具有一些額外的特點(diǎn)。

我過(guò)去建議人們使用文件系統(tǒng)快照，特別是LVM快照。這些快照也可以創(chuàng)建備份，而又不會(huì)打斷數(shù)據(jù)庫(kù)的操作。但經(jīng)過(guò)一些基準(zhǔn)測(cè)試，我和我的同事都不再推薦這種方法了。LVM的問(wèn)題是影響性能，而且比我們過(guò)去認(rèn)為的影響要大得多。其他有快照能力的文件系統(tǒng)，如ZFS，相對(duì)比較新，我也不是這方面的專家，所以也就沒(méi)什么可說(shuō)的。我的有些客戶使用 Solaris和ZFS，盡管很難分離各個(gè)變量，或者直接比較性能，但我并不認(rèn)為性能有明顯的好轉(zhuǎn)。ZFS寫(xiě)時(shí)復(fù)制(copy-on-write)的行為，使得關(guān)于數(shù)據(jù)如何物理組織的考慮變得很復(fù)雜了，關(guān)于這方面，我還沒(méi)有足夠的時(shí)間來(lái)熟悉，所以也就無(wú)法做出合理的推薦。所以，在我看來(lái)，將ZFS用做數(shù)據(jù)庫(kù)的文件系統(tǒng)，還仍然沒(méi)有取得一致意見(jiàn)。所以，在開(kāi)源領(lǐng)域，我還沒(méi)有見(jiàn)到基于快照的備份的殺手級(jí)解決方案。

關(guān)于MYSQLI的，而MYSQL沒(méi)有這種能力，所以，MYSQL的備份就有點(diǎn)復(fù)雜了。很多數(shù)據(jù)庫(kù)都有內(nèi)置的熱備能力，如果你的數(shù)據(jù)庫(kù)有，就使用它。前面的討論大部分都是對(duì)于MYSQL，可能其他數(shù)據(jù)庫(kù)也一樣，可以用復(fù)制從服務(wù)器來(lái)做這樣的事:將復(fù)制延遲一段時(shí)間，如一個(gè)小時(shí)。這可以使用Maatkitt的mk-slave-delay工具來(lái)實(shí)現(xiàn)。將延遲的服務(wù)器用

做“備份”，有下面兩個(gè)有趣的點(diǎn):

● 不斷地從主服務(wù)器中獲取更新，但并不應(yīng)用這些更新，這意味著，比起昨天晚上做的備份(在發(fā)生崩潰的時(shí)候，備份的數(shù)據(jù)可能已經(jīng)過(guò)去24小時(shí)了)，丟失數(shù)據(jù)的機(jī)會(huì)要低得多。在延遲時(shí)間到達(dá)時(shí)，服務(wù)器將應(yīng)用從主服務(wù)器中獲取的更新。

● 假如發(fā)生問(wèn)題，這種延遲會(huì)給你一段緩沖時(shí)間。偶然的DROP TABLE，在你的從服務(wù)器上會(huì)延遲一個(gè)小時(shí)才會(huì)發(fā)生，所以，在又對(duì)主服務(wù)器上的表進(jìn)行恢復(fù)等類似操作時(shí)，可以跳過(guò)從服務(wù)器上DROP，并將從服務(wù)器切換為主服務(wù)器。這段額外的延遲時(shí)間，給了恢復(fù)操作相當(dāng)?shù)倪x擇空間。
 
將延遲從網(wǎng)站建設(shè)服務(wù)器用做備份的補(bǔ)充，而不是替代。你仍然需要做實(shí)際的備份!