重要的是在表丟失和毀壞時備份數據庫。如果系統發生崩潰，您就能夠將表恢復到崩潰時刻的狀態，並盡可能不丟失數據。同樣，錯發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的輸入使用的輸出結果，以重建數據庫。
可以將整個數據庫按以下命令轉儲到單獨的文本文件中：
該文件的其余部分由更多的INSERT 和CREATE TABLE 語句組成。如果想在生成備份時進行壓縮，可替換成類似下列的命令：
% mysqldump samp_db | gzip > /usr/archives/MySQL/samp_db.1999.10.02.gz
如果您有一個超大數據庫，則該輸出文件也將是極大的且管理起來很困難。如果您喜歡的話，可以通過在MySQLdump 命令的數據庫名之後命名單個的表來轉儲這些表的內容。這個操作將該轉儲文件分成更小的、更多的可管理的文件。下面的例子將說明如何將samp_db 的一些表轉儲到單個文件中：
% MySQLdump samp_db student score event absence > gradebook.sql
% MySQLdump samp_db member president > hist-league.sql
如果您正在生成備份文件並打算用這些備份文件來定期刷新另一個數據庫的內容，則可能要使用--add-drop-table 選項。此選項告訴MySQLdump 將DROP TABLE IF EXISTS 語句寫到備份文件中。然後，當您取出該備份文件並將其加載到第二個數據庫時，如果表已經存在將不會出現錯誤信息。如果您正在運行第二個數據庫，可使用此技術利用從第一個數據庫中的數據拷貝來定期地加載它。
如果您正在轉儲數據庫使該數據庫可以轉換到另一個服務器上，則無須創建備份文件。應確保該數據庫存在於另一台主機上，然後用一個管道使mysql直接讀取MySQLdump 的輸出結果來轉儲數據庫。例如，如果想要將samp_db 數據庫從p i t _ v i per.snake.Net 拷貝到b o a . s n a k e . n e t，操作如下：
% MySQLadmin -h boa.snake.Netcreate samp_db
% mysqldump samp_db | MySQL-h boa.snake.Net samp_db
稍後，如果想要在boa.snake.Net 中再次刷新該數據庫，可跳過mysqladmin 命令，但要將--add-drop-table 增加到MySQLdump 中，以避免得到有關“表已經存在”的錯誤：
% mysqldump --add-drop-table samp_db | MySQL-h boa-snake.Net samp_db
MySQLdump 的其他選項包括如下所示的幾個：
--flush-log 和--lock-tables 的結合有助於檢查數據庫。--lock-table 鎖定所有正在轉儲的表，而--flush-log 關閉並重新打開更新日志文件。如果正在產生後續的更新日志，則新的更新日志將只包含從備份的那一點開始修改數據庫的查詢。這時檢查對於該備份時間的更新日志的檢查點（然而，鎖定所有的表對於備份期間客戶機訪問來說不太好，如果您有需要執行更新操作的客戶機的話）。
如果用--flush-logs 檢查對於備份時間的更新日志檢查點，最好轉儲整個數據庫。如果轉儲單個文件，則將更新日志的檢查點與備份文件同步是比較難的。在恢復操作中，您通常在總數據庫（ per- d a t a b a s e）的基礎上抽取更新日志的內容。對於抽取單個表的更新日志來說沒有選項，因此您必須自己抽取它們。
缺省設置時，mysqldump 將表的全部內容在寫之前讀到內存中。這實際上不是必須的，事實上，如果您真的有大型表的話，這幾乎是一個失敗的方法。可以用--quick 選項告訴MySQLdump 寫每一行（只要是被檢索的）。要想進一步優化該轉儲過程，可用- - o p t來代替- - q ui c k。-- opt 選項開啟其他的選項，這些選項將加快轉儲數據和讀回數據的速度。
由於快速備份的好處，使得用--opt 執行備份成為最常用的方法。但是，要當心， - - o p t 選項有一個代價： --opt 所優化的是您的備份過程，而不是由其他客戶機對數據庫的訪問。--opt 選項可防止任何人更新被鎖定的正在轉儲的任何表。您會很容易地發現在常
規數據庫訪問中在這一點上所做的努力。試著在一天中數據庫通常最繁忙的時刻運行一個備份。這不會花費太多的時間。
與--opt 作用有點相反的選項是- d e l a y e d。該選項導致MySQLdump 寫INSERT D E L AYED 語句而非INSERT 語句。如果您將一個數據文件加載到另一個數據庫中並且想要使該操作對其他查詢（這些查詢可能正在數據庫中發生）造成的影響最小，則- -d e l a y e d將有助於達到這個目的。
--compress 選項有助於將數據庫拷貝到另一台機器上，因為它可以減少網絡傳輸中的字節數量。這裡有一個例子，請注意，為了使程序與遠程主機上的服務器進行通信（而不是與本地主機通信），給出了--compress 選項：
% mysqldump --opt samp_db | MySQL--compress -h boa.snake.Net samp_db
MySQLdump 有許多選項，詳細信息請參考附錄E。
使用直接拷貝數據庫備份和拷貝方法
不用MySQLdump 來備份數據庫或表的另一種方法是直接拷貝表文件。通常可利用像c p、tar 或cpio 這樣的實用程序來進行。本節的例子使用的是c p。
使用直接拷貝備份（ direct-copy backup）方法時，必須確保沒有使用這些表。如果在拷貝一個表的同時服務器正在修改它，則拷貝無效。
確保拷貝完整性的最好方法是關閉服務器，拷貝文件，然後重新啟動服務器。如果不想關閉服務器，則應參考第13 章，查閱有關在執行表檢查點時鎖定服務器的介紹。如果服務器在運行中，則相同的約束都適用於拷貝文件，您應該用同樣的鎖定協議使服務器保持靜止狀態。
假定服務器關閉，或者已經鎖定了想要拷貝的表，下面的例子將說明怎樣將整個samp_db 數據庫備份到備份目錄中（ DATADIR 代表服務器的數據目錄）：
% cd DATADIR
% cp -r samp_db /usr/archive/MySQL 單個表可按如下進行拷貝：
% cd DATADIR/samp_db
% cd member.* /usr/archive/MySQL/samp_db
% cd score.* /usr/archive/MySQL/samp_db
...
當完成備份時，可以重新啟動服務器（如果已使它關閉），或者釋放在表上施加的鎖（如果保持服務器運行）。
要想用直接拷貝文件將數據庫從一台機器拷貝到另一台機器，只要將這些文件拷貝到另一台服務器主機上的相應數據庫上即可。應確保這些文件是對MyISAM 表的或者兩台機器都有相同的硬件結構。否則這些表在第二個主機上看起來好象有很奇怪的內容。還應該確保第二台主機的服務器不會在您安裝這些表時去訪問它們。
復制數據庫
術語“復制”的含義簡單地說有點像“拷貝數據庫到另一個服務器”，或者是包含在主數據庫的內容發生變化時次數據庫的有效更新（ live updating）的含義。如果想簡單地將數據庫拷貝到另一個服務器上，則可以使用在前面已經討論的那些命令。自MySQL3.23 版本以來，就已經開始出現對基於有效更新的復制的支持。但它的功能仍未成熟，因此，在這方面筆者沒有什麼可討論的，如果有興趣，您可以注意一下當前的新版本，看看有些什麼新的開發功能。
