備份是否完整，能否滿足要求，關鍵是要看所設計的備份策略是否合理，以及備份操作是否按照所設計的備份策略進行了。
針對不同的用途，所需要的備份類型也是不一樣的，備份策略也各不相同，下面根據我的個人經驗，掰一掰MYSQL的備份策略。
1、對於較爲核心的在線應用系統，必須要在線備用主機通過MYSQL AB複製進行相應的備份，複製線程要一直打開，恢復線程可以每天恢復一次，儘量讓備機得數據延後主機的時間在一定時間間隔內。這個延後時間多長主要根據實際需求來定，一般來說延後一天是一個比較常規的做法。
2、對於重要級別稍微低一些的應用，恢復時間要求不是太高的話，爲了節約硬件成本，不必使用在線的備份主機來單獨運行備用的MYSQL,可以通過一定的時間週期進行一次物理全備份，同時每小時（或者其他合適的時間段）都將產生的二進制日誌進行備份。這樣雖然沒有第一種備份方法恢復快，但是數據的丟失會比較少。恢復所需要的時間由全備份週期長短決定
3、對於恢復基本沒有太多時間要求，但是不希望太多的數據丟失的場景，則可以在一定時間週期內進行一次邏輯全備份，同時也備份相應的二進制日誌。使用邏輯備份而不使用物理備份的原因是因爲邏輯備份實現簡單，可以完全在線聯機完成，備份過程不會影響應用提供服務。
4、對於一些搭建臨時數據庫的備份應用場景，僅僅須要通過一個邏輯全備份即可滿足需求，都不許要用二進制日誌來進行恢復，因爲這樣的需求對數據並沒有太苛刻的要求。
上述備份策略僅提供一個參考，具體因實際應用場景可靈活變通。