重要的是在表丟失和毀壞時備份數據庫。如果系統發生崩潰，您就能夠將表恢復到崩潰時刻的狀態，並盡可能不丟失數據。同樣，錯發DROP DATABASE 或DROP TABLE 命令的用戶可能會向您請求進行數據恢復。有時，這是由MySQL管理員引起的破壞，管理員試圖通過使用像vi 或emacs 這樣的編輯器直接編輯表文件而毀壞了它們。這樣做對表來說肯定是干了壞事。
備份數據庫的兩種主要方法是使用mysqldump 程序或直接拷貝數據庫文件（如便用c p、tar 或c p i o）。每種方法都有自己的優點和缺點：
mysqldump 與MySQL服務器聯合進行操作。直接拷貝方法與服務器相脫離，因此必須采取措施確保在進行拷貝時沒有客戶機在修改這些表。這個問題與利用文件系統備份來備份數據庫的問題相同：如果數據庫表在文件系統備份時進行更新，則進行備份的表文件處於非一致的狀態，並且對於今後恢復該表沒有意義。文件系統備份和直接拷貝文件的區別是：對於後者，您具有控制備份進度的權利，因此可以采取措施確保服務器使表處於靜止狀態。
mysqldump 比直接拷貝技術要慢。
mysqldump 產生可移植到其他機器、甚至具有不同硬件結構的機器上的文本文件。直接拷貝文件不能夠移植到其他機器上，除非要拷貝的表使用MyISAM 存儲格式。ISAM 表只能在具有相同硬件結構的機器之間進行拷貝。例如，將文件從S PARC 的Solaris 機器拷貝到Intel 的Solaris 機器（或者相反）是行不通的。由MySQL3.23 引進的MyISAM 表存儲格式可以解決這個問題，因為該格式與機器獨立。因此，如果以下兩個條件都滿足的話，直接拷貝文件可以移植到具有不同硬件結構的機器上：即另一台機器上也必須運行MySQL3.23 以上的版本，並且文件必須表示成MyISAM 表，而不是ISAM 表。
不論選擇哪種備份方法，都有某些原則，您必須堅持這些原則，才能確保在需要恢復數據庫內容時得到最好的結果：
定期執行備份。設置一個時間表並堅持使用它。
告訴服務器運行更新日志。更新日志在您需要恢復崩潰後的數據庫時給予幫助。在使用備份文件將數據庫恢復到備份時刻的狀態後，可以通過運行更新日志中的查詢，重新運行備份之後所做的改變。這個操作將數據庫中的表恢復到了崩潰時刻的狀態。在文件系統備份語言中，數據庫備份文件表示完全轉儲（ full dump），而更新日志則表示增量轉儲。
使用一致和可理解的備份文件命名模式。像b a c k up 1、backup2 等名字沒有特殊的含義。當需要它執行恢復時，還得浪費時間去查看文件中的內容。您會發現使用數據庫名和花時間去構造備份文件名是有好處的。例如：
% mysqldump samp_db> /usr/archives/mysql/samp_db. 1999-10-02
% mysqldump menagerie> /usr/archives/mysql/menagerie.1999-10-02
在產生備份文件後您可能需要將它們壓縮。畢竟備份文件都比較大，所以您可能還需要終止備份文件以避免它們填滿磁盤，這與終止日志文件類似。您可以用相同的技術終止備份文件：
用文件系統備份來備份您的備份文件。如果您遭受了一個完全崩潰，不僅毀壞了數據目錄而且還破壞了包含數據庫備份的磁盤驅動器，那將造成真正的麻煩。您還應該備份更新日志。
將備份文件放在與您的數據庫不同的文件系統上。這將減少含有數據字典的文件系統被生成的備份文件填滿的可能性。
創建備份的技術對於將數據庫拷貝到另一個服務器上也是很有幫助的。將數據庫轉移到運行在另一個主機上的服務器是很平常的，但您還可以將數據轉移到運行在相同主機上的另一個服務器。如果正為一個新版本的MySQL運行服務器，並且想用成品服務器上的某些真實數據來測試它時，可能會這樣做。還有一種可能，那就是您得到了一台新的機器並要將所有的數據庫移動到新機器上。
用mysqldump 備份和拷貝數據庫
當使用mysqldump 程序產生數據庫備份文件時，缺省設置是該文件的內容由C R E AT E TABLE 語句組成，這些語句創建被轉儲的表以及包含表中的行數據的INSERT 語句。換句話說，mysqldump 創建在今後可作為對mysql的輸入使用的輸出結果，以重建數據庫。
