● 在備份上不要拖延，做備份其實并不難。
● 做事不要追求完美，而要追求可恢復。
● 至少對于可接受的數據損失、可接受的宕機時間、數據持續策略以及安全需求要形成文檔。
● 對恢復過程要進行練習并形成文檔，恢復比備份要重要得多!
● 對于備份作業成功與否，要進行外部驗證，不要依賴于作業自身對你的提示。
下面，讓我們將繁文縟節的形式拋在一邊，看看怎么用復制從服務器做備份。
首先，最顯然的事情，是將從服務器自身作為備份。不幸的是，這并非一個真正的備份。在發生問題時，如丟失了服務器或其一部分、惡意攻擊造成的數據破壞、偶然的DROPTABLE，真正的備份能夠挽回損失，而復制從服務器對于上述后兩個問題所造成的數據損失，卻是無能為力的，因為它只是好心地將數據變化復制了過來，從而將數據的破壞或損失也一并復制了過來。
所以，怎么做真正的備份呢?假如只有一臺復制從服務器，而且這臺服務器也有多余的空間做cron作業等，則在不用數據庫服務器的時候，將其停掉，然后備份其數據。對于MYSQL:在 MYSQL進程運行的時候，不要復制IINNODB的文件，這樣是無法復制的。如果能夠停掉MYSQL，然后將其數據移走，則對于大多數情況，都是最安全的。
如果不想停止服務器，還有一個選擇，就是Ktrabackup，一個免費和開源的非阻塞備份程序，用于備份INNODB和KTRADBE的表。假如有 MYISAM表，則在復制時會進行鎖定。Xtrabackup基于與INNODBI的熱備工具同樣的原理，但 XTRADB開源，且具有一些額外的特點。
我過去建議人們使用文件系統快照，特別是LVM快照。這些快照也可以創建備份，而又不會打斷數據庫的操作。但經過一些基準測試，我和我的同事都不再推薦這種方法了。LVM的問題是影響性能，而且比我們過去認為的影響要大得多。其他有快照能力的文件系統，如ZFS，相對比較新，我也不是這方面的專家，所以也就沒什么可說的。我的有些客戶使用 Solaris和ZFS，盡管很難分離各個變量，或者直接比較性能，但我并不認為性能有明顯的好轉。ZFS寫時復制(copy-on-write)的行為，使得關于數據如何物理組織的考慮變得很復雜了，關于這方面，我還沒有足夠的時間來熟悉，所以也就無法做出合理的推薦。所以，在我看來，將ZFS用做數據庫的文件系統，還仍然沒有取得一致意見。所以，在開源領域，我還沒有見到基于快照的備份的殺手級解決方案。
關于MYSQLI的，而MYSQL沒有這種能力，所以，MYSQL的備份就有點復雜了。很多數據庫都有內置的熱備能力，如果你的數據庫有，就使用它。前面的討論大部分都是對于MYSQL，可能其他數據庫也一樣，可以用復制從服務器來做這樣的事:將復制延遲一段時間，如一個小時。這可以使用Maatkitt的mk-slave-delay工具來實現。將延遲的服務器用
做“備份”，有下面兩個有趣的點:
● 不斷地從主服務器中獲取更新，但并不應用這些更新，這意味著，比起昨天晚上做的備份(在發生崩潰的時候，備份的數據可能已經過去24小時了)，丟失數據的機會要低得多。在延遲時間到達時，服務器將應用從主服務器中獲取的更新。
● 假如發生問題，這種延遲會給你一段緩沖時間。偶然的DROP TABLE，在你的從服務器上會延遲一個小時才會發生，所以，在又對主服務器上的表進行恢復等類似操作時，可以跳過從服務器上DROP，并將從服務器切換為主服務器。這段額外的延遲時間，給了恢復操作相當的選擇空間。
將延遲從網站建設服務器用做備份的補充，而不是替代。你仍然需要做實際的備份!
本文地址：http://murenxiang.com.cn//article/3321.html
