現在是評估、測試和關注備份的時候了。目前令人糾結的問題是對云進行評測,以判斷我們自己是否需要去擔憂云備份。如果真是那樣的話,我們又該如何做呢?
我對云服務的現狀了解得越深,我對我所發現的現象就越擔憂。每一家廠商都有完全不同于其他廠商的備份政策,有些廠商甚至沒有備份政策。
服務型基礎設施(IaaS)廠商在這方面做得似乎是最差的。我們經常認為公共云上的虛擬機和存儲服務是所向無敵的。
當巨人隕落之時
這與事實相差甚遠。即使是最強大的亞馬遜也曾在一年前丟失過客戶的數據。
試想一下,連亞馬遜也丟失過客戶數據啊。我們說的可不是古老的Co-Lo和數據托管服務。 這可是一家剛剛從IBM手中搶走了中情局數據中心合同訂單的公司。
亞馬遜也不能保證客戶數據百分之百不丟失,但它可是云技術領域中的精英。
你可以將你的數據交給亞馬遜云平臺的多個區域托管,但是如果你的運氣不好的話,仍有可能遇到多個區域的服務同時宕機的事故。
你也許能夠找到一家公共云廠商為你提供足夠多的備份副本,而且那些備份分布在很多存儲層級上以保證你的數據萬無一失,但這只是針對工作區的保障措施,而不是真正的備份。
工作區技術比如高效率、容錯等等可以在基礎設施出現故障時對數據進行保護。它們并不能防止數據輸入時出現巨大錯誤或意外刪除。
我們只是人
在現實世界里,僅僅避免基礎設施故障是不夠的。你不可避免地會在很多時候遇到一些情況,必須提取和使用以前某個時間點的數據備份。
你將永遠也不能用技術取代人在數據收集過程中所發揮的作用。如果不是McFumblefingers將信息壓縮成一種形式并提交,那就是能與API通訊的腳本或從常用文件夾讀取輸入文件。 隨著API的不斷發展,輸出格式也變得各不相同了。
在某些情況下,修改是為了解決安全方面的問題。在其他情況下,它可能只是一個政客修改夏時制以節約時間或某些國家宣布獨立。 總是有些東西需要更新。更新最終是要由人來完成的,因此犯錯將是難免的。
這意味著需要對版本進行控制,也就是對增量備份進行控制。如果你是在自己的基礎設施上運行自己的云,那么備份將是非常容易的一件事。VSphere可以拍下正在運行的虛擬機的快照,Unitrends或類似的服務可以將一切都備份下來。
你甚至可以利用Asigra等軟件將數據或數據副本備份到公共云上。我選擇Asigra是因為它似乎可以提供幾種不同類型的云備份。
我不想將我的數據保存在美國。Asigra可以滿足我這方面的要求,作為一家受控服務供應商,我可以將客戶的數據備份在我這里。