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

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

● 對恢復過程要進行練習并形成文檔，恢復比備份要重要得多!

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

首先，*顯然的事情，是將從服務器自身作為備份。不幸的是，這并非一個真正的備份。在發(fā)生問題時，如丟失了服務器或其一部分、惡意攻擊造成的數(shù)據破壞、偶然的DROPTABLE，真正的備份能夠挽回損失，而復制從服務器對于上述后兩個問題所造成的數(shù)據損失，卻是無能為力的，因為它只是好心地將數(shù)據變化復制了過來，從而將數(shù)據的破壞或損失也一并復制了過來。

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

如果不想停止服務器，還有一個選擇，就是Ktrabackup，一個免費和開源的非阻塞備份程序，用于備份INNODB和KTRADBE的表。假如有 MYISAM表，則在復制時會進行鎖定。Xtrabackup基于與INNODBI的熱備工具同樣的原理，但 XTRADB開源，且具有一些額外的特點。

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

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

做“備份”，有下面兩個有趣的點:

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

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