備份規則與虛擬備份

我最近在The Register網站(www.theregister.co.uk)上閱讀到一篇題爲「備份神話」的好文章，當時我就想這是一個很好的博客主題，由於，許多人備份作的不好而本身卻渾然不知。因此，借鑑於該篇文章( http://www.theregister.co.uk/2013/07/12/storagebod_monomyth/)，我發表如下觀點（許多內容是通過我修改的）。

每一個人都知道須要備份，嗯，每一個人都知道本身須要採用某種方式保護本身的數據。雖然保護數據有多種方式，可是，備份確實是一種很好的方式。

爲把工做作好、作到極致，你就必須準確無缺地備份全部重要數據，並對備份數據進行加密保護，將備份數據保存在另外一個地方而且進行恢復測試，以便知足及時恢復的目標，至少是季度恢復目標，不然的話就達不到效果。

設計恢復策略及目標- 許多人都有本身的備份目標及方法，如，天天進行備份，備份在某些目錄下，保存7天等等。可是，他們不多考慮到如何使用備份進行數據恢復，尤爲是恢復何種數據、何人何地以及如何進行數據恢復工做等等，以及恢復須要花費多長時間。設計您的恢復目標，而後採用備份來實現該目標，而後測試是否可以實現該目標。

按需備份- 許多人備份全部東西，備份整個服務器。或者，他們認爲，須要備份的東西太多就不備份了。尤爲是，相比公司或數據中心局域網而言，互聯網數據量大，備份是一份更痛苦的工做。您應該先設想一下您的恢復流程及如何進行數據恢復，而後備份所需備份的東西實現數據恢復。尤爲須要注意的是：不要備份OS，僅備份您構建系統時所須要的某些數據，如etc目錄。

複製不等於備份- 咱們發現有許多客戶，他們有不少從機，因此他們覺得沒有必要進行備份工做。從許多層面來看，這確實是一個拙劣的想法，但若是數據損壞、表格丟失或者關鍵數據被刪除或更改掉呢？

僅僅備份從機數據並不是上策- 對於MySQL而言，因爲許多緣由，主從機不一樣步是司空見慣的事情。若不使用Percona優越的pt-table-checksum工具來驗證從機數據的話，根本沒法徹底相信從機數據的正確性。若是您運行這個工具的話（您必須運行這個工具），您能夠放心地備份從機。否則的話，您仍是能夠繼續備份從機數據，可是要考慮到100%的數據正確性是何等的重要（可能沒有這麼嚴重），仍是要進行恢復測試及數據抽檢。注意：若是您常常是從從機上讀取數據而且實際用戶也沒有抱怨過數據錯誤的話，那麼您的從機是確實很好的，可是，仍是使用Percona 工具比較好。

RAID 不是備份- 的確，當RAID可以工做的很好的時候，對於保存在線數據確實頗有幫助，可是，無論從何種定義來看，RAID毫不是備份。

數據備份對於開發/測試（Dev/Test）是頗有益處的 – 按期（如每週）爲開發及測試進行數據備份可以簡便快速地測試備份及恢復。可是，一般此類數據是頗有價值的數據，因此，最好不要在開發員電腦、辦公數據庫或易訪問的測試系統中毫無限制地暴露這些數據。最佳的作法是：採用匿名數據，即在數據進入開發或測試系統前，變動電子郵件、物理地址、名稱、電話號碼等等，將這些數據變動爲隨機的代碼。不要由於備份安全性較差，輕易地泄露有價值的數據。

對備份進行加密保護 – 將備份從所在的機器移出以前，需對其進行加密保護，以免數據在傳輸過程當中被竊取，這樣，不管是經過局域網、互聯網、磁帶、FTP或是任何途徑進行數據傳輸，都不會被竊取。將備份數據從服務器中移出以前，須使用簡單的密鑰進行數據保護，固然，還必須時刻當心保管好數據並不時地測試密鑰。

更新備份- 系統變動時常發生，尤爲是在互聯網上。你必須每一個季度進行檢查，以確保你備份的是正確的數據，好比你上個月新增的數據庫，此外，還須確保已包括了重命名的圖片目錄及新增的Redis系統。儘管備份測試數據也是有益處的，可是，很容易會丟失新/更改後的目錄、數據及服務。

最後，確保備份可以有效工做 – 您如何知道呢？您天天有備份報表嗎？這報表告訴你備份的數據的大小嗎？這樣，當您期待5 GB的數據的時候，您就不會備份500KB的數據 （您可能會驚詫奇怪這個事情常常發生）。最後，檢查備份是否有效的惟一途徑是對整個系統的備份數據進行恢復及測試，包括配置數據、網絡對象、代碼及數據等等。

瞭解備份、喜好備份、並對其進行加密和測試。備份每一數據，日夜備份。

（ Authored  by  Steve  Mushero  |  ChinaNetCloud  CEO  &  CTO  本博客英文原文請點擊查看,  ）