Mysql 備份方案

容災恢復：硬體故障、不經意的 bug 導致資料損壞，或者伺服器及其資料由於某些原因不可獲取或無法使用等（例如：機房大樓燒毀，惡意的黑客攻擊或 mysql 的 bug 等）。

人們改變想法：很多人經常會在刪除某些資料後，又想恢復這些資料。

審計：有時需要知道資料或 schema 在過去的某個時間點的狀態和資料，或發現了應用的乙個 bug，想知道在此之前發生了什麼等等。

測試：定期使用生產資料來更新測試伺服器（備份是為了恢復，這樣也可以驗證備份的資料是否完整，是否能夠正常還原等）。如果備份的方案非常簡單，只需要將備份檔案還原到測試伺服器上即可。

規劃備份和恢復策略時，有兩個重要的需求：恢復點目標（rpo）定義了可以容忍丟失多少資料，恢復時間目標（rto）定義了需要等待多久將資料恢復。

最大的權衡是備份時間與備份負載。可以犧牲其一以增強另外乙個。例如，可以降低伺服器效能，來提高備份的優先順序。

邏輯備份（也叫「匯出」）和直接複製原始檔案的物理備份。邏輯備份將資料報含在一種 mysql 能夠解析的格式中，要麼是 sql，要麼是以某個符號分隔的文字。原始檔案是指存在硬碟上的檔案。

■  必須由資料庫伺服器完成生成邏輯備份工作，因此要使用更多的 cpu 週期。

■  無法保證匯出後再還原出來的一定時同樣的資料。浮點表示問題、軟體 bug 等都會導致問題，儘管非常少見。

■  從邏輯備份中還原需要 mysql 載入和解釋語句，轉化為儲存格式，並重建索引，所有這一切都會很慢。

物理備份，優點如下：

■  基於檔案的物理備份，只需要將需要的檔案複製目標位址即可完成備份。不需要其他額外的工作來生成原始檔案。

■  物理備份的恢復可能更簡單，取決於儲存引擎。對於 myisam 只需要簡單的複製檔案到目的地即可。對於 innodb 則需要停止資料庫服務，可能還要採取其他一些步驟。

■  innodb 和 myisam 的物理備份非常容易跨平台、作業系統和 mysql 版本。

■  從物理備份中恢復會更快，因為不需要執行任何 sql 和構建索引。如果有很大的 innodb 表，無法完全快取再記憶體中，則物理備份的恢復要快非常多，只是要快乙個數量級。事實上，邏輯備份最可怕的地方就是不確定的還原時間。

【物理備份的缺點如下】：

■  innodb 的原始檔案通常比相應的邏輯備份要大的多。innodb 的表空間往往包含很多未使用的空間。還有很多空間被用來做儲存以外的用途（插入緩衝，回滾段等）。

■  物理備份不總是可以跨平台、作業系統及 mysql 版本。檔名大小寫敏感和浮點格式是可能會遇到的麻煩。很可能因浮點格式不同而不能移動檔案到另乙個系統。

物理備份簡單高效，但也容易出錯。儘管如此對於長期保留的備份，還是很適合的。但盡量不要完全依賴物理備份。至少每隔一段時間還是需要做一次邏輯備份。建議混合使用物理和邏輯兩種方式來做備份：先使用物理複製，以此資料啟動 mysql 伺服器例項並執行 mysqlcheck。然後周期性地使用 mysqldump 執行邏輯備份。這樣做可以獲得兩種方法的優點，不會使生產伺服器在匯出時過度負擔。如果能夠利用檔案系統的快照，也可以生成乙個快照，將該快照複製到另乙個伺服器上並釋放，然後測試原始檔案，再執行邏輯備份。

備份檔案一定要經過資料恢復測試，特別是物理備份。不要自認為資料備份是正常的，這樣容易釀成大錯。對 innodb 來說，這意味著需要啟動乙個 mysql 例項，執行 innodb 恢復操作，然後執行 check tables。也可以跳過這一操作，僅對檔案執行 innochecksum（是乙個用於校驗 innodb 表空間檔案完整性的工具，是乙個官方自帶的工具），但不建議這樣做。

當資料量很龐大時，乙個常見的策略是做定期的增量或差異備份。差異備份是對自上次全量備份後所有改變的部分而做的備份，而增量備份則是從任意型別的上次備份後所有修改做的備份。

例如，週日做乙個全備份，在周一，對週日以來所有的改變做乙個差異備份。在周二，就有兩個選擇：備份自週日以來所有的改變（差異），或只備份自從周一備份後所有的改變（增量）

■  使用 percona xtrabackup 和 mysql enterprise backup 等軟體中的增量備份特性。

■  備份二進位制日誌。可以在每次備份後使用 flush logs 來開始乙個新的二進位制日誌，這樣就只需要備份新的二進位制日誌。

■  不要備份沒有改變的表。myisam 引擎會記錄每個表最後修改時間。可以通過檢視磁碟上的檔案或執行 show table status 來看這個時間。如果使用 innodb 可以利用觸發器記錄修改時間到乙個表中。

■  不要備份沒有改變的行。如果乙個表只是做插入，可以增加一列（時間戳），然後只備份自上次備份後插入的行。

■  備份所有資料，然後傳送到乙個有去重特性的目的地，例如 zfs 檔案管理程式。

增量備份的缺點：增加恢復複雜性，額外的風險，以及更長的恢復時間。如果可以全備，考慮到簡便性，盡量經常做全備。建議至少一周一次，週內通過增量的方式進行備份。

最簡單的策略是只備份資料和定義表，但這是乙個最低的要求。在生產環境中恢復資料庫一般需要更多的工作，例如：

非顯著資料：不要忘記那些容易被忽略的資料，例如：二進位制日誌和 innodb 事務日誌等。

**：mysql 伺服器可以儲存許多**，例如觸發器和儲存過程。如果備份了 mysql資料庫，大部分這類**也就備份了，但此時如果還原單個業務資料庫會比較麻煩。

複製配置：如果恢復乙個設計複製關係的伺服器，應該備份所有與複製相關的檔案（二進位制日誌、中繼日誌、日誌索引檔案和.info 檔案）。至少應該包含 show master status 和 show sl**e status 的輸出。執行 flush logs 也非常有好處，可以讓 mysql 從乙個新的二進位制日誌開始。從日誌檔案的開頭做基於故障時間點的恢復要比從中間更容易。

伺服器配置：如果需要從災難中恢復，這時需要在新資料中心構建伺服器，如果此時備份中包含伺服器配置會免去很多任務作。

選定的作業系統檔案：對於伺服器配置來說，備份中對生產伺服器至關重要的任務外部配置，都十分重要。在 unix 伺服器上，這可能包括 cron 任務（實現 linux 定時任務）、使用者和組的配置、管理指令碼，以及 sudo（是 linux 系統管理指令，是允許系統管理員讓普通使用者執行一些或者全部的 root 命令的乙個工具） 規則。

mysql 對儲存引擎的選擇會導致備份明顯更複雜。如何對給定的儲存引擎後，得到一致的備份。實際上有兩類一致性需要考慮：資料一致性和檔案一致性。

mysql 備份方案 mysql備份方案

1.環境說明 系統為centos 6.5 需要安裝mutt和msmtp並可以傳送郵件 需要安裝python 2.6.6 需要安裝xtrabackup 2.備份方案功能模組介紹 備份 使用xtrabackup進行備份，每次備份會把備份檔案放到乙個當前日期和時間的資料夾內。所以建立備份夾new，把備份檔...

MYSQL 備份方案

例如 周一完全，周二增量，週三增量，周四差異，那麼周四備份就是周二增量備份的加上週三增量備份的。cp備份，tar複製資料庫檔案 資料量少 mysqldump 複製binlog 資料量還行，先用mysqldump對資料進行完全備份，再定期備份binlog到達增量備份效果 lvm2快照 複製binlog...

mysql 資料庫備份方案

1.資料庫備份方案 1 沒備份，跑路 2 全量備份 增量備份 如果不小心 刪庫 可以這麼恢復 a.將最近一次全量備份的全庫找到，拷貝回來 檔案一般比較大 解壓，應用 b.將最近一次全量備份後，每一天的增量binlog找到，拷貝回來 檔案較多 依次重放 c.將最近一次增量備份後，到執行 刪全庫 之前的...