0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫(xiě)文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

如何保證數(shù)據(jù)安全,防止云端數(shù)據(jù)丟失

存儲(chǔ)界 ? 來(lái)源:未知 ? 作者:工程師郭婷 ? 2018-08-29 16:58 ? 次閱讀

云計(jì)算時(shí)代,企業(yè)應(yīng)用和數(shù)據(jù)完全上云后,如果數(shù)據(jù)丟失,找不到了,企業(yè)應(yīng)該怎么辦?

這是任何一個(gè)企業(yè)都不能回避的問(wèn)題。當(dāng)企業(yè)的數(shù)據(jù)全部上云,云計(jì)算提供商又保證有多重措施保護(hù)用戶數(shù)據(jù)的安全。但是,當(dāng)真正的災(zāi)難降臨時(shí),作為企業(yè)生命的全部數(shù)據(jù)找不回了,企業(yè)該怎么辦?能怎么辦?只能未雨綢繆,做事后諸葛亮!

斷服務(wù)常見(jiàn),數(shù)據(jù)丟失卻異常罕見(jiàn)隨著企業(yè)上云進(jìn)程的加劇,企業(yè)應(yīng)用和數(shù)據(jù)完全上云越來(lái)越多。但是云服務(wù)商提供的服務(wù)卻不能完全百分之百滿足用戶的需求。毋庸置疑,“永不掉線”是云服務(wù)商愿景的核心部分,100%的高可用性卻成為難以保證的“奢求”。

目前。世界上大部分公有云服務(wù)商都出現(xiàn)過(guò)服務(wù)器宕機(jī)、服務(wù)中斷的情況。而且原因也五花八門(mén)。對(duì)于企業(yè)用戶來(lái)說(shuō),在享受云服務(wù)帶來(lái)的便利的同時(shí),也面臨著云服務(wù)宕機(jī)帶來(lái)的巨大挑戰(zhàn)。云服務(wù)中端對(duì)用戶而言最直接的損失就是說(shuō)造成業(yè)務(wù)中端,對(duì)一些關(guān)鍵業(yè)務(wù)系統(tǒng)而言,業(yè)務(wù)中端的損失是巨大的。在過(guò)去的一年時(shí)間里,摩拜先后四次發(fā)生大范圍的宕機(jī)事件,其中三次宕機(jī)全部出現(xiàn)在上班早高峰時(shí)期。頻繁的在重要時(shí)間段出現(xiàn)故障,已經(jīng)在不斷降低自己的品牌形象和用戶信任感。

但是因?yàn)樵品?wù)中斷而造成用戶數(shù)據(jù)全部丟失確實(shí)比較罕見(jiàn)。所以,企業(yè)需要根據(jù)自身的需求提前制定數(shù)據(jù)管理策略,并應(yīng)用全面的數(shù)據(jù)管理解決方案,確保云中數(shù)據(jù)安全無(wú)虞。

事后諸葛亮!牢記三大教訓(xùn)不但要保證數(shù)據(jù)安全,最重要的是防止數(shù)據(jù)丟失,在云計(jì)算時(shí)代對(duì)用戶而言確實(shí)是一大挑戰(zhàn)。建議用戶層從三個(gè)層面來(lái)規(guī)劃。

第一, 在企業(yè)上云的過(guò)程中,多云成為一個(gè)上佳策略。多云被廣泛認(rèn)為是云計(jì)算的未來(lái),多云本身就是不把雞蛋放在一個(gè)籃子里。多云指的是在業(yè)務(wù)架構(gòu)內(nèi)使用多個(gè)云計(jì)算供應(yīng)商和提供商(跨公共平臺(tái)和專用平臺(tái)),從而使組織能夠根據(jù)其特定要求將不同的工作負(fù)載分散到不同的環(huán)境中。

混合云是公有云、私有云兩種的任意混合,是目前最受推崇的一種多云方式,為企業(yè)提供兩全其美的解決方案,將私有云的控制性與公共平臺(tái)提供的業(yè)務(wù)敏捷性相結(jié)合。面臨的最大挑戰(zhàn)是公有云+私有云的管理。好在深圳企有意云服務(wù)科技有限公司推出的云幫手,是一款集中化服務(wù)器運(yùn)維管理工具。能夠支持多臺(tái)服務(wù)器可視化管理,監(jiān)控告警,日志分析等便捷功能。提供跨云多平臺(tái)一站式批量云服務(wù)器安全管理服務(wù)。

第二,多云戰(zhàn)略下,公用云的選擇要與時(shí)俱進(jìn)。公有云逐步走向成熟,并成為香餑餑后,各路大佬們一并涌了過(guò)來(lái)。粗略估計(jì),目前對(duì)外提供公有云服務(wù)的平臺(tái)和品牌,大大小小有上百家。目前依靠?jī)r(jià)格戰(zhàn)已經(jīng)很難吸引更多的用戶,畢竟公有云越來(lái)越透明。

究竟選擇哪種公有云?如何衡量公有云平臺(tái)現(xiàn)有及未來(lái)的實(shí)力?這是一個(gè)大話題,很難回答。專家認(rèn)為,如果從滿足客戶需求和價(jià)值創(chuàng)造角度出發(fā),基本上可以劃分為三層階梯式的考量維度:一是能否滿足業(yè)務(wù)需要 ; 二是總體擁有成本的高低 ; 三是能不能引領(lǐng)業(yè)務(wù)創(chuàng)新。

最起碼的一點(diǎn),互聯(lián)網(wǎng)產(chǎn)品的技術(shù)架構(gòu)講究用戶的承載力和伸縮性,有沒(méi)有經(jīng)過(guò)規(guī)?;?yàn)證,是評(píng)判公有云平臺(tái)穩(wěn)定性、可靠性、擴(kuò)展性的重要指標(biāo)。

另外。要考察云服務(wù)商是否有豐富、完整的生態(tài)體系的支持。企業(yè)級(jí)服務(wù)與消費(fèi)市場(chǎng)一個(gè)區(qū)別就是特別強(qiáng)調(diào)生態(tài)的構(gòu)建。產(chǎn)業(yè)鏈上的合作伙伴越多,越能形成合力,生態(tài)的勢(shì)能才足夠大,最終形成強(qiáng)勢(shì)的競(jìng)爭(zhēng)壁壘。

第三,在云環(huán)境下,也要考慮考慮容災(zāi)備份目前,容災(zāi)備份已經(jīng)成為一個(gè)信息系統(tǒng)的必備部分,這已經(jīng)不是一個(gè)簡(jiǎn)單的技術(shù)問(wèn)題,而是一個(gè)管理策略問(wèn)題。但是沒(méi)有容災(zāi)備份系統(tǒng)的信息系統(tǒng)的企業(yè)比例卻非常高。

當(dāng)用戶的系統(tǒng)上云以后,要不要容災(zāi)備份,企業(yè)用戶經(jīng)常會(huì)更糾結(jié),因?yàn)樵品?wù)商已經(jīng)提供了非常好的容災(zāi)備份系統(tǒng)。

聲明:本文內(nèi)容及配圖由入駐作者撰寫(xiě)或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問(wèn)題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • 數(shù)據(jù)
    +關(guān)注

    關(guān)注

    8

    文章

    6760

    瀏覽量

    88619
  • 云計(jì)算
    +關(guān)注

    關(guān)注

    39

    文章

    7670

    瀏覽量

    137018
  • 云服務(wù)
    +關(guān)注

    關(guān)注

    0

    文章

    798

    瀏覽量

    38828

原文標(biāo)題:云端數(shù)據(jù)丟失怎么辦?謹(jǐn)記三大教訓(xùn)!

文章出處:【微信號(hào):cunchujie,微信公眾號(hào):存儲(chǔ)界】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。

收藏 人收藏

    評(píng)論

    相關(guān)推薦

    假如服務(wù)器的數(shù)據(jù)丟失,如何快速恢復(fù)丟失數(shù)據(jù)?

    在服務(wù)器數(shù)據(jù)丟失后,快速恢復(fù)丟失數(shù)據(jù)是至關(guān)重要的,以避免業(yè)務(wù)中斷和數(shù)據(jù)損失。以下是一些方法和步驟,可以幫助企業(yè)快速有效地恢復(fù)
    的頭像 發(fā)表于 08-08 16:59 ?233次閱讀

    AN87216雙向數(shù)據(jù)傳輸數(shù)據(jù)丟失是什么原因引起的?

    測(cè)試 AN87216 ,雙向數(shù)據(jù)傳輸數(shù)據(jù)丟失數(shù)據(jù)或問(wèn)題,請(qǐng)問(wèn)這個(gè)是可能什么引起,謝謝!
    發(fā)表于 07-24 06:50

    使用CYW20829的BLE進(jìn)行最大數(shù)據(jù)發(fā)送應(yīng)用,BLE丟失數(shù)據(jù)如何解決?

    用作發(fā)送數(shù)據(jù)的任務(wù)之一,我發(fā)現(xiàn)每次發(fā)送 244 個(gè)數(shù)據(jù)時(shí),都需要延遲以確保數(shù)據(jù)正確傳輸,如果取消延遲,就會(huì)丟棄幾組 244 個(gè)數(shù)據(jù)。 如圖所示。 我猜測(cè)可能是藍(lán)牙堆棧的內(nèi)部緩沖區(qū)被填滿
    發(fā)表于 07-23 07:56

    TCP傳輸大量數(shù)據(jù)時(shí)丟失數(shù)據(jù)的原因?

    當(dāng)TCP用于傳輸大量數(shù)據(jù)時(shí),要找到數(shù)據(jù)丟失的地方,當(dāng)TCP傳輸大量數(shù)據(jù)時(shí),數(shù)據(jù)丟失,包錯(cuò)。 具
    發(fā)表于 07-12 15:03

    聚徽觸控-平板工控機(jī)數(shù)據(jù)丟失如何處理

    工控器廠家已經(jīng)針對(duì)工業(yè)平板電腦數(shù)據(jù)丟失等問(wèn)題,提出了一些恢復(fù)方法,幫助用戶解決數(shù)據(jù)丟失的困擾。以下是詳細(xì)資料:
    的頭像 發(fā)表于 06-16 10:57 ?387次閱讀

    服務(wù)器數(shù)據(jù)恢復(fù)—OceanStor存儲(chǔ)中卷數(shù)據(jù)丟失數(shù)據(jù)恢復(fù)案例

    華為OceanStor某型號(hào)存儲(chǔ)。工作人員在上傳數(shù)據(jù)時(shí)發(fā)現(xiàn)該存儲(chǔ)上一個(gè)NAS卷數(shù)據(jù)丟失,管理員隨即關(guān)閉系統(tǒng)應(yīng)用,停止上傳數(shù)據(jù)。這個(gè)丟失
    的頭像 發(fā)表于 06-14 13:42 ?185次閱讀
    服務(wù)器<b class='flag-5'>數(shù)據(jù)</b>恢復(fù)—OceanStor存儲(chǔ)中卷<b class='flag-5'>數(shù)據(jù)</b><b class='flag-5'>丟失</b>的<b class='flag-5'>數(shù)據(jù)</b>恢復(fù)案例

    數(shù)據(jù)庫(kù)數(shù)據(jù)恢復(fù)—Sql Server數(shù)據(jù)庫(kù)文件丟失數(shù)據(jù)恢復(fù)案例

    庫(kù)。存儲(chǔ)空間LUN劃分了兩個(gè)邏輯分區(qū)。 服務(wù)器故障&初檢: 由于未知原因,Sql Server數(shù)據(jù)庫(kù)文件丟失,丟失數(shù)據(jù)涉及到3個(gè)庫(kù),表的數(shù)量有3000左右。
    的頭像 發(fā)表于 04-11 15:38 ?747次閱讀
    <b class='flag-5'>數(shù)據(jù)</b>庫(kù)<b class='flag-5'>數(shù)據(jù)</b>恢復(fù)—Sql Server<b class='flag-5'>數(shù)據(jù)</b>庫(kù)文件<b class='flag-5'>丟失</b>的<b class='flag-5'>數(shù)據(jù)</b>恢復(fù)案例

    請(qǐng)問(wèn)NFC數(shù)據(jù)傳輸如何保證數(shù)據(jù)安全?

    NFC數(shù)據(jù)傳輸如何保證數(shù)據(jù)安全
    發(fā)表于 04-07 06:18

    ram中存儲(chǔ)的數(shù)據(jù)在斷電后是否會(huì)丟失?

    當(dāng)電源斷開(kāi)時(shí),隨機(jī)存取存儲(chǔ)器(RAM)中的數(shù)據(jù)通常會(huì)丟失。這是因?yàn)镽AM是一種易失性存儲(chǔ)器,它必須以恒定的電源供應(yīng)來(lái)維持存儲(chǔ)的數(shù)據(jù)。在斷電時(shí),RAM中的電荷會(huì)逐漸耗盡,導(dǎo)致其中的數(shù)據(jù)
    的頭像 發(fā)表于 01-16 16:30 ?7279次閱讀

    如何保證kafka消息不丟失

    如果在簡(jiǎn)歷上寫(xiě)了使用過(guò)kafka消息中間件,面試官大概80%的概率會(huì)問(wèn)你:"如何保證kafka消息不丟失?"反正我是屢試不爽。
    的頭像 發(fā)表于 12-19 09:52 ?664次閱讀
    如何<b class='flag-5'>保證</b>kafka消息不<b class='flag-5'>丟失</b>

    FPGA讀ad7401數(shù)據(jù)時(shí),F(xiàn)PGA發(fā)出的時(shí)鐘如果在線路上有丟失,AD7401還能輸出正確的MDATA嗎?

    FPGA讀ad7401的數(shù)據(jù)時(shí)。FPGA發(fā)出的時(shí)鐘如果在線路上有丟失,AD7401還能輸出正確的MDATA嗎?有沒(méi)有一套機(jī)制是防止時(shí)鐘信號(hào)丟失的。
    發(fā)表于 12-07 08:03

    進(jìn)程寫(xiě)文件會(huì)丟失數(shù)據(jù)

    進(jìn)程寫(xiě)文件(使用緩沖 IO)過(guò)程中,寫(xiě)一半的時(shí)候,進(jìn)程發(fā)生了崩潰,會(huì)丟失數(shù)據(jù)嗎? 答案,是不會(huì)的。 因?yàn)檫M(jìn)程在執(zhí)行 write (使用緩沖 IO)系統(tǒng)調(diào)用的時(shí)候,實(shí)際上是將文件數(shù)據(jù)寫(xiě)到了內(nèi)核
    的頭像 發(fā)表于 11-13 10:57 ?571次閱讀
    進(jìn)程寫(xiě)文件會(huì)<b class='flag-5'>丟失</b><b class='flag-5'>數(shù)據(jù)</b>嗎

    請(qǐng)問(wèn)如何接收和解析單片機(jī)串口的數(shù)據(jù),怎么防止丟失和斷貞?

    請(qǐng)問(wèn)大家如何接收和解析單片機(jī)串口的數(shù)據(jù),怎么防止丟失和斷貞呢?
    發(fā)表于 11-08 07:57

    服務(wù)器數(shù)據(jù)恢復(fù)—誤還原快照導(dǎo)致SqlServer數(shù)據(jù)庫(kù)數(shù)據(jù)丟失數(shù)據(jù)恢復(fù)案例

    服務(wù)器數(shù)據(jù)恢復(fù)環(huán)境: vmfs文件系統(tǒng),存放的是SqlServer數(shù)據(jù)庫(kù)及其他辦公文件。 服務(wù)器故障: 工作人員誤操作還原快照,導(dǎo)致了SqlServer數(shù)據(jù)庫(kù)數(shù)據(jù)
    的頭像 發(fā)表于 11-06 15:06 ?610次閱讀