盡管如此，許多人仍繼續(xù)遵循著一種“設定好就一勞永逸”的模式。很大比例的用戶仍舊依賴 SaaS提供商在其平臺中嵌入的更多功能工具來備份數(shù)據(jù)。這一群體中的許多人并不一定排斥更強大的備份方式，他們只是在假設他們不需要更多保護的情況下如此進行而已。
這群人是在冒險。他們還沒有遭遇過急需備份數(shù)據(jù)的情況。無論是數(shù)據(jù)丟失事件、用戶管理失敗還是自動化故障，他們都是在進行著一場賭博，一場不知賠率的賭博。雖然這場賭博可能并不是災難性的，但他們可能會對后果感到驚訝。
從效率的角度來看，SaaS 顯然好處多多，不僅入門門檻很低，而且組織還可以利用OpEx模式，讓他們按需付費。SaaS應用程序還可以無縫集成到現(xiàn)有機制里（例如用于身份管理的多因素驗證），并且 SaaS 提供商通常提供設計、配置、優(yōu)化和管理數(shù)據(jù)中心可能沒有的解決方案的專業(yè)知識。
然而，過度依賴SaaS提供商可能會產生一定的后果。一方面，組織對服務交付或其運行的基礎設施沒有太多的控制權。 雖然這可以被視為一個好處，但如果確實發(fā)生什么事情，那就是一個問題了。事實上，這總體上說明了影響以這種方式提供的服務細節(jié)的能力。
常見誤區(qū)
公司在向云轉移時最大的安全/數(shù)據(jù)保護誤區(qū)，是 SaaS提供商并不能夠滿足你的一切要求。最好的例子是向Microsoft 365的轉移，因為許多組織從本地 Exchange 轉移到 SharePoint。Microsoft 365 的用戶理所當然地認為，任何涉及應用程序、網絡控制、操作系統(tǒng)和物理網絡的任何中斷都將由 SaaS提供商來管理。
但大部分的宕機并不是由 SaaS供應商本身造成的，而是其他人造成了問題（要么是圖謀不軌，要么只是人為犯錯而已）。迄今為止，最大的問題是意外刪除，如果您沒有強大的備份，您的數(shù)據(jù)可能會丟失。這個情況就像租車一樣：SaaS 提供商確保汽車加滿油，隨時可以上路，但一旦您把車開到路上，那就要對發(fā)生的事情負責了。
歷史證明，每當一種新模式流行起來時，人們就會對某些問題的發(fā)展做出錯誤的假設。數(shù)據(jù)備份方面正在發(fā)生著類似這種的情況。IT 決策者了解轉移部署、升級和容量轉移的責任的好處，但許多人并沒有意識到，數(shù)據(jù)的實際責任通常由租戶承擔。SaaS 提供商的責任共擔模型清楚地說明了這一點：數(shù)據(jù)仍將由客戶負責。而且這是唯一在整個云中的一致的東西。
制定備份策略
以下是組織在制定 SaaS 備份策略時應考慮的幾個問題：
有備無患——為未知的難題做好準備是一件很難的事情。但是，如果您有數(shù)據(jù)，您很好地會處理此類事件。如果您為未知事件準備好SaaS應用程序，您將做到數(shù)據(jù)可控。
假設最壞的情況——不管何種情況，壞事皆有可能發(fā)生。它可能不會涉及設備故障，因為從基礎架構角度來看，云有很好的彈性。但是一旦有了數(shù)據(jù)，就會發(fā)生問題。
牢記合規(guī)性——雖然監(jiān)管機構通常要求組織將數(shù)據(jù)保留數(shù)年，但 SaaS 備份通常最多設置 120 天。 如果您不提前考慮，而往往會在事后才發(fā)現(xiàn)，屆時將很難恢復沒有備份的內容了。
責任到位——組織應該非常熟悉他們的SaaS 提供商所提供的責任共擔模型。您必須了解您的數(shù)據(jù)在哪里，并能夠推動“電子探查情況“。
做好退出策略的計劃——協(xié)商退出策略的成本和方法的最佳時間是在集成 SaaS 備份解決方案之前，因為提供商有可能會以他們當下確定的價格來扣押您的數(shù)據(jù)。
結語
隨著組織轉向 SaaS 來運行其關鍵任務的業(yè)務功能，他們會更加關注數(shù)據(jù)備份的重要性。但許多人仍然低估了他們的數(shù)據(jù)所面臨的風險。數(shù)據(jù)是他們的命脈，而完全依賴SaaS備份可能會讓他們猛然醒悟。（本文由Veeam 企業(yè)戰(zhàn)略副總裁 Dave Russell撰寫）
