在數據庫表丟失或損壞的情況下，備份你的數據庫是很重要的。如果發生系統崩潰，你肯定想能夠將你的表盡可能丟失最少的數據恢復到崩潰發生時的狀態。有時，正是MySQL管理員造成破壞。管理員已經知道表以破壞，用諸如vi或EMacs等編輯器試圖直接編輯它們，這對表絕對不是件好事！
備份數據庫兩個主要方法是用MySQLdump程序或直接拷貝數據庫文件（如用cp、cpio或tar等）。每種方法都有其優缺點：
mysqldump與MySQL服務器協同操作。直接拷貝方法在服務器外部進行，並且你必須采取措施保證沒有客戶正在修改你將拷貝的表。如果你想用文件系統備份來備份數據庫，也會發生同樣的問題：如果數據庫表在文件系統備份過程中被修改，進入備份的表文件主語不一致的狀態，而對以後的恢復表將失去意義。文件系統備份與直接拷貝文件的區別是對後者你完全控制了備份過程，這樣你能采取措施確保服務器讓表不受干擾。
MySQLdump比直接拷貝要慢些。
mysqldump生成能夠移植到其它機器的文本文件，甚至那些有不同硬件結構的機器上。直接拷貝文件不能移植到其它機器上，除非你正在拷貝的表使用MyISAM存儲格式。ISAM表只能在相似的硬件結構的機器上拷貝。在MySQL 3.23中引入的MyISAM表存儲格式解決了該問題，因為該格式是機器無關的，所以直接拷貝文件可以移植到具有不同硬件結構的機器上。只要滿足兩個條件：另一台機器必須也運行MySQL 3.23或以後版本，而且文件必須以MyISAM格式表示，而不是ISAM格式。
不管你使用哪種備份方法，如果你需要恢復數據庫，有幾個原則應該遵守，以確保最好的結果：
定期實施備份。建立一個計劃並嚴格遵守。
讓服務器執行更新日志。當你在崩潰後需要恢復數據時，更新日志將幫助你。在你用備份文件恢復數據到備份時的狀態後，你可以通過運行更新日志中的查詢再次運用備份後面的修改，這將數據庫中的表恢復到崩潰發生時的狀態。
以文件系統備份的術語講，數據庫備份文件代表完全傾倒（full dump），而更新日志代表漸進傾倒（incremental dump）。
使用一種統一的和易理解的備份文件命名機制。象backup1、buckup2等不是特別有意義。當實施你的恢復時，你將浪費時間找出文件裡是什麼東西。你可能發覺用數據庫名和日期構成備份文件名會很有用。例如：
%mysqldump samp_db >/usr/archives/MySQL/samp_db.1999-10-02
%mysqldump menagerIE >/usr/archives/MySQL/menagerIE.1999-10-02
你可能想在生成備份後壓縮它們。備份一般都很大！你也需要讓你的備份文件有過期期限以避免它們填滿你的磁盤，就象你讓你的日志文件過期那樣。
用文件系統備份備份你的備份文件。如果遇上了一個徹底崩潰，不僅清除了你的數據目錄，也清除了包含你的數據庫備份的磁盤驅動器，你將真正遇上了麻煩。也要備份你的更新日志。
將你的備份文件放在不同於用於你的數據庫的文件系統上。這將降低由於生成備份而填滿包含數據目錄的文件系統的可能性。
用於創建備份的技術同樣對拷貝數據庫到另一台機器有用。最常見地，一個數據庫被轉移到了運行在另一台主機上的服務器，但是你也可以將數據轉移到同一台主機上的另一個服務器。
