1. 3-2-1原则
1.1. 每份数据做三个副本
1.2. 放到两种介质上
1.3. 其中一份放在远处
1.4. 3-2-1原则是全部备份工作的底子原则
2. 数据保护即服务
2.1. Data-Protection-as-a-Service,DPaaS
2.2. 信息安满是一个跟数据保护完全差别的学科
3. 软件即服务
3.1. Software as a Service
3.2. SaaS
4. 为什么要把这么多钱投到备份与灾难恢复上？
4.1. 数据备份是一件很紧张的事
4.2. 备份本身并不是重点，重点在于必须有备份，才能够从中恢复数据
- 4.2.1. 没人关心你能不能备份
- 4.2.2. 只关心你能不能从备份中恢复数据
4.3. 不做备份的人，不太可能在数据保护工作方面成功
4.4. 备份、恢复以及DR变得比原来更为紧张，而且更复杂
4.5. 在计划数据保护系统之前，必须先把相关的需求收集到位
4.6. 人为错误
4.7. 机械故障或系统故障
4.8. 自然灾害
5. 人为错误
5.1. 在大多数情况下，之所以要做数据恢复与灾备，就是因为有人犯了错误，让盘算情况遭到粉碎，这种错误可能是无心的，也可能是故意的
- 5.1.1. 人难免犯错
- 5.1.2. 有时可能并没有恶意，但却把数据给删除或粉碎掉了，这就是我们要做备份的另一项原因
5.2. 操纵失误
- 5.2.1. 人总是会失误
- 5.2.1.1. 可能会把错误的文件复制到错误的地方
- 5.2.1.2. 拿一份没用的文件把一份有用的文件覆盖掉
- 5.2.2. user error
- 5.2.2.1. 用户错误或用户操纵失误
- 5.2.2.2. IT部门中的系统管理员、网络管理员与数据管理员，同样容易出这种错误
5.2.2.2.1. 拿到管理员权限相当于拥有一把利剑，如果砍错了方向，可能会造成严重的后果
5.2.2.2.2. 之所以要备份数据，一个很紧张的原因就在于应对管理员的失误
- 5.2.3. PEBKAC
- 5.2.3.1. Problem Exists Between Keyboard And Chair
5.2.3.1.1. 问题出在键盘和椅子之间
- 5.2.4. 把数据内里不该删的数据表给删了
- 5.2.5. 把不该格式化的盘（即一个原来毫无问题的盘）给格式化了
- 5.2.6. 把开辟用的数据库恢复到了生产用的数据库（即给实际产物用的数据库）上
- 5.2.7. 原来想写个脚本把那些用不到的home目次给删掉，结果这个脚本把每一位用户的home目次全都删掉了
- 5.2.8. 把不该删的假造机(Virtual Machine, VM)给删了
5.3. 代码错误
- 5.3.1. 代码错误到处都有
- 5.3.1.1. 软件通常也会运行在权限较高的模式下，因此有可能会损坏大量数据
- 5.3.1.2. 由于那种软件会有成百上千的公司安装，因此其中如果隐蔽着什么问题，那么一旦爆发，就会造成相当大的危害
5.4. 恶意攻击
- 5.4.1. 有人故意要搞粉碎
- 5.4.2. 恶意攻击数据中心，是经常发生的事情
- 5.4.3. 真正的仇人就是那些想通过某种形式的电子攻击来粉碎这个构造的人
- 5.4.4. 绝不会知道网络攻击会从那里发起
- 5.4.5. 每次更新软件时都应该先验证，看它是否有安全漏洞（或者说安全隐患）
- 5.4.6. 备份数据保留得比现有筹划稍长一些
5.5. 恐怖攻击
- 5.5.1. 恐怖攻击是你必须遵循3-2-1原则的另一个来由
- 5.5.2. 如果放置数据库副本的服务器离主站只有数百码（1码=0.9144米），那这种DR方案就不够稳妥
- 5.5.2.1. 其中一套备份放在间隔受保护的数据比较远的地方
- 5.5.2.2. Disaster Recovery，DR
5.5.2.2.1. 灾难恢复
5.6. 电子攻击
- 5.6.1. 你的构造更有可能遭受的，应该是某种形式的电子攻击（也叫网络攻击）
- 5.6.2. 入侵手段根本就都没有利用防火墙的漏洞，它们利用的都是人的某种弱点，以促使员工本身去打开这个后门
- 5.6.2.1. 通过网络钓鱼(phishing)或者社交欺骗的手段安插的，攻击者会利用这些手段，诱导员工把恶意代码直接下载到他的工作情况内里
- 5.6.3. 攻击者通过给手机充电的线缆来部署恶意软件
5.7. 勒索软件
- 5.7.1. ransomware
- 5.7.2. 如果针对的是个人，那可能是几百美元，如果针对的是比较大的构造，那可能是上百万美元
- 5.7.3. 恶意软件与勒索病毒已经横行很久了
- 5.7.4. RaaS
- 5.7.4.1. Ransomware-as-a-Service，勒索病毒即服务
- 5.7.4.2. 让很多人都能相当容易地发起勒索攻击
- 5.7.4.3. 你只要说出本身想攻击谁，并提供一些有助于入侵的信息，他们就会帮你执行勒索攻击
5.7.4.3.1. 如许的犯罪团伙完满是为了谋利，他们会从勒索到的财帛内里分走很大一部分
- 5.7.4.4. RaaS出现之后，就不再有这个停滞了，只要知道怎样进入暗网(dark web)并联系到提供RaaS的团伙，就可以发动勒索攻击
- 5.7.4.5. 勒索病毒也随着RaaS模式的鼓起变得越来越猖狂，这种攻击对数据造成的风险与日俱增
5.8. 内部威胁
- 5.8.1. 很多构造都没有对从内部发起的攻击做好准备，其实这种攻击也会给数据带来丧失
- 5.8.2. 就算某些攻击不是从内部发起的，它也需要内部因素的共同才能实现
- 5.8.3. 最常见的内部威胁，来自对本构造不满的正式员工或条约工，他们会利用手中的权限来损害公司的产业
- 5.8.4. rogue admin（“流氓”管理员）问题
- 5.8.4.1. 拥有特权，因此能够悄悄地对数据造成极大粉碎
- 5.8.4.2. 植入一些能够在本身离职之后，继续粉碎原公司数据的代码
- 5.8.4.3. Yung-Hsun Lin（音译：林永勋）变乱
5.8.4.3.1. 2004年给公司的70台服务器安装了所谓的“逻辑炸弹”(logic bomb)
5.8.4.3.2. 是一个脚本，他怕公司将其解雇，所以编写了这个脚本，一旦公司把他炒掉，他就通过触发该脚原来删除服务器中的全部数据，以此抨击公司
5.8.4.3.3. 于2006年获罪
- 5.8.4.4. 如果有人能不受限制地使用Windows系统的Administrator（管理员）账户、UNIX与Linux系统的root（根）账户或其他操纵系统中的类似账户，那么就能十拿九稳地变身为一个rogue admin，让你很难追查他所造成的粉碎
- 5.8.5. 系统管理员拥有很高的权限。因此你必须尽力限制这些拥有特权的人在做出恶意行为时有可能波及的范围
- 5.8.5.1. 让他们总是以本身的身份登录系统
5.8.5.1.1. 每个人都应该用本身的名字登录
5.8.5.1.2. 就算要获取root或Administrator权限，也必须先以本身的名字登录，然后再通过某种留存有记录的机制来获取管理权限
5.8.5.1.3. 只管限制或制止他们使用那种必须以root或Administrator身份运行的工具
- 5.8.5.2. 不要把root密码告诉任何人
5.8.5.2.1. 把root或Administrator账户的密码设置成一个随机的字符串，没有人知道这个字符串具体是什么
5.8.5.2.2. 为了让想要获取root或Administrator权限的人，必须先以本身的身份登录，然后再通过sudo或Run as Administrator（以系统管理员身份执行）等手段来获取管理权限
5.8.5.2.3. 全部的操纵都会留有记录
- 5.8.5.3. 删除或禁用那种能够提供shell情况（命令行执行情况）的程序
5.8.5.3.1. 用户以root身份运行vi，那么就可以通过这个机制进入一个有root权限的shell界面，并在其中不被记录地执行恣意命令
- 5.8.5.4. 让超级用户只能通过控制台登录
5.8.5.4.1. 用户只能通过控制台(console)登录
5.8.5.4.2. 一定要把能够实际打仗到控制台的访问行为记录下来
5.8.5.4.3. 针对假造控制台的访问行为记录下来
- 5.8.5.5. 启用主机之外的记录机制
5.8.5.5.1. 凡是有人访问超级用户的账户（无论这次访问是否颠末授权），都应该记录成一次安全变乱，并把相关信息（例如视频监控画面或针对假造控制台而设的日记）稳妥地保存下来，让网络入侵者无法删除这份证据
5.8.5.5.2. 就算有人想要粉碎系统，他也不可能容易地抹除本身的踪迹
- 5.8.5.6. 不让盘算机从其他启动盘里启动
5.8.5.6.1. 只管设法制止用户从系统盘之外的其他启动盘启动服务器或假造机
- 5.8.6. 将各种权限分离
- 5.8.6.1. 备份与DR系统是最后一道防线，因此应该由完全差别的一方来管理，而且你不能让这个管理方有机会粉碎你所要保护的底子设施
- 5.8.7. 基于角色的管理
- 5.8.7.1. role-based administration
- 5.8.7.2. 把数据保护系统内里的各个部分交给差别的人来管理，这些人各自具备差别的权力
- 5.8.7.3. 把备份策略的配置权（也就是界说权）与操纵权（也就是执行权）分开，能够限制其中一方所拥有的权力
5.8.7.3.1. 一种角色可能拥有日常的备份操纵权，也就是说，此类人员可以执行预先界说好的备份任务
5.8.7.3.1.1. 这些人无权修改备份策略
5.8.7.3.2. 备份策略的修改权，把握在另一种角色的手里，然而他们固然能修改备份策略
5.8.7.3.2.1. 无权执行这些策略
- 5.8.7.4. 恢复工作可能会由一个与上述两者完全差别的角色负责
5.8.7.4.1. 以防止此类人员利用数据恢复功能，将数据泄漏到本构造之外
- 5.8.7.5. 从安全角度看，最好能把备份系统中的每个角色指派给差别的人
5.8.7.5.1. 并不能完全消除来自内部的威胁，但确实可以大幅降低这种概率
- 5.8.8. 最低权限
- 5.8.8.1. 一定要保证每个人与每个程序都只获得了执行其工作所必需的权限，而没有获得与其工作无关的权限
- 5.8.9. 多人认证机制
- 5.8.9.1. 多人认证/多人授权(multiperson authentication)机制
- 5.8.9.2. 多重认证（multifactor authentication，也叫多因素认证）机制
5.8.9.2.1. 在执行某项操纵之前，必须同时获得两人同意
5.8.9.2.2. 四眼授权(four-eyes authentication)，因为会有两双眼睛盯着这个事情
- 5.8.9.3. 某些数据保护产物要求用户同时获得两个人的许可，如此才能执行恢复操纵、修改备份策略或淘汰某个备份的保留时间
6. 机械故障或系统故障
6.1. 关键的工作数据现在都保存在某种形式的固态介质上
6.2. 存储设备比原来更加健壮，而且任何一个器重数据的数据中心，都会配备RAID如许的冗余存储机制以及纠删码(erasure coding)技术
- 6.2.1. 整个RAID阵列中的磁盘同时故障的情况相当少见，但也不是从来没有发生过
6.3. 设备的固件内里内置完整性检查(integrity checking)逻辑，宁肯让数据无法保存，也不让磁盘发生故障
- 6.3.1. 很少出现因为硬盘故障而恢复数据的情形，但这并不意味着这种情形绝不会发生
6.4. 目前的系统与数据库已经能够应对许多数据问题，因此由物理故障及系统故障所造成的数据丧失，应该不会很常见
- 6.4.1. 很少遇到这种因发生机械故障而必须恢复数据的情形，但如许的情形确实存在
6.5. 电力停止
- 6.5.1. 任何一个颇具规模的数据中心，都会有冗余电源与大型发电机
- 6.5.2. 结构化的数据根本上应该不会受到粉碎，因为数据库有内置的数据完整性检查机制，不会让结构上有问题的数据写到数据库内里
- 6.5.3. 无结构的数据（也叫非结构化的数据）根本上也应该没事，只是停电那一刻正在写入的少数几个文件可能会有点问题
6.6. 云平台没有那么神奇
- 6.6.1. 并没有所谓云(cloud)这个东西，它还是得依靠别人的盘算机来实现
- 6.6.2. 云平台没有那么神奇，它本质上还是一批给你提供服务的盘算机而已
- 6.6.3. 云平台所支持的各种数据存储机制，从数据保护的角度看，是有所区别的
- 6.6.3.1. 采用对象存储(object storage)机制来保存的数据，可以在多个位置上存留多份副本，因此能够担当多次事故
- 6.6.3.2. 采用块存储(block storage)机制来保存的数据，则只是假造驱动器内里的一个LUN（Logical Unit Number，逻辑单位号），这个假造的驱动器仅位于某一间数据中心的某一个存储阵列内里
6.6.3.2.1. 这种存储方式没有任何冗余机制，因此采用该方式存储的数据必须加以备份
6.7. 系统故障
- 6.7.1. 无论你用的是仅依赖某一个存储阵列的单一服务器（由差别位置的多个数据中心所构成的大型服务器集群），还是由云端所提供的服务，都无法保证其完善无缺
- 6.7.2. 软件与硬件未必总是按照预想的方式运作，因此我们必须做备份
7. 自然灾害
7.1. 自然灾害是我们必须遵循3-2-1原则的一个紧张原因
7.2. 盘算机不但怕水，它还怕火
7.3. 水患
- 7.3.1. 数据中心可能受各种原因影响而发生水患
- 7.3.2. 就大水这一因素而言，数据保存得越高越好
- 7.3.3. 要确保DR站完全位于大水的波及范围之外
- 7.3.4. 把DR站放在间隔主站较近的位置，但是要保证它比主站更高
7.4. 火灾
- 7.4.1. 烧毁数据中心的不一定是山火，也有可能是那种因为短路而引发的火灾
- 7.4.2. 电路内里要有断路器(breaker)，以便在短路时自动跳闸，然而这种断路器未必总是能及时跳闸
- 7.4.3. 火对数据中心会造成巨大损害
- 7.4.4. 有许多种与备份及数据恢复无直接关系的办法，均能防止数据中心失火
- 7.4.5. 防火也是我们要备份数据的一项原因
7.5. 地震
- 7.5.1. 应对地震，关键是要做好准备
- 7.5.1.1. 建筑方面的法规也要求建筑物内里的东西必须绑住。就连热水器也是绑住的
- 7.5.1.2. 数据中心的机架（rack，也叫机柜）放在防震座上，让我们可以在地板出现震动的情况下移动机架
- 7.5.2. 确保DR站位于伤害范围之外
- 7.5.2.1. 由于地震的伤害范围通常会局限在某一个区域内，因此这一点并不是很难做到
7.6. 飓风、台风、旋风
- 7.6.1. 应对飓风的关键在于把DR筹划所依据的系统，放在完全不受飓风扰乱的地方
7.7. 龙卷风
- 7.7.1. 龙卷风是一种猛烈的旋转风暴，它会把巨大的粉碎力集中在某一点上
- 7.7.2. 应对龙卷风的关键，也在于让DR站远离频发龙卷风的地带
7.8. 落水洞
- 7.8.1. 又叫渗穴、天坑
- 7.8.2. 这种灾害能够像龙卷风那样，对某地施以外科手术式的打击，同时又像地震那样无法预测
- 7.8.3. 经历过龙卷风的人，会说风刮得跟货运车颠末时一样，而落水洞则是突然出现的，它不声不响地带来巨大伤害
- 7.8.4. DR站一定要放在远离主站的地方
- 7.8.5. 从每平方英里的角度看，落水洞的出现数量好像很少，但问题在于，这种现象随时有可能发生
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
