读数据保护:工作负载的可规复性26商用数据备份方案 ...

打印 上一主题 下一主题

主题 840|帖子 840|积分 2520


1. 备份简史

1.1. 20世纪80年代中期各人都还没有意识到,运行着商用UNIX操纵系统的大型工作环境里,应该配备一款商用的备份软件或某种自动的磁带系统
1.2. 1993年备份工作全都是通过shell脚本与cron job形式的计划使命来实现的

  • 1.2.1. 脚本总是假定服务器中必要备份的数据肯定可以或许装到一盘备份磁带里
1.3. FRU

  • 1.3.1. Field-Replaceable Unit,可当场更换的部件
1.4. 磁带柜又一次改变了备份工作的面貌

  • 1.4.1. 备份系统可以或许通过磁带柜的机器手臂,自动给磁带制作副本
  • 1.4.2. 某些磁带柜还可以把晚上制作好的磁带网络到一个特制的抽屉里,第二天早上抽出来给我们看
2. 确定备份系统的规模

2.1. 采用的方式大概是加强现有的产品,也大概是彻底换用新的产品
2.2. 必须把该系统的规模确定下来,然后才能去考虑购买与此规模相适应的备份方案
2.3. 了解必要购买多少硬件、软件、磁带或磁盘
2.4. 考虑的因素

  • 2.4.1. 做一次完全备份必要占用多少存储空间
  • 2.4.1.1. 相当紧张
  • 2.4.1.2. 初次制作完全备份之后,还需不必要继续制作如许的完全备份了?
  • 2.4.1.3. 如果必要,那么每隔多久做一次?
  • 2.4.2. 有待备份的数据在日常工作中的变革频率
  • 2.4.2.1. 最好的办法是参考目前这个备份系统日常制作增量备份时所需占据的空间
  • 2.4.3. RTO(目标规复时间)
  • 2.4.4. RPO(目标规复点)
  • 2.4.5. 如果我们不知道该系统必须在多长时间内完成规复(RTO),也不知道最多答应丢失多少数据(RPO),那就无法设计出合适的备份系统
  • 2.4.6. 备份在站内与站外必要保留多久
  • 2.4.6.1. 一个不能由设计备份系统的团队本身去推测的指标
  • 2.4.6.2. 你们的构造一般会从多久之前制作的备份里规复数据
  1. >  2.4.6.2.1. 备份系统的管理员可以直接帮上忙的
复制代码

  • 2.4.6.3. 法律法规是否要求某些数据必须多保留一段时间
  • 2.4.6.4. 是否必要确保某些数据一定会在某段时间之后予以删除
  • 2.4.6.5. 如果必要保存的时间特别长,那就应该考虑将其作为档案,而不是备份来予以保存了
  • 2.4.7. 制作备份的时间段
  • 2.4.7.1. 备份窗口或备份时段
  • 2.4.7.2. 一定要就“何时可以制作备份”告竣共识
  • 2.4.7.3. 如果你们设计的备份系统是从文件级别来制作增量备份与完全备份的,那么必须把这个窗口定下来
  1. >  2.4.7.3.1. 这种系统在制作备份的过程中会给执行正式工作的生产系统带来很大负担,对于完全备份来说,这种负担尤其严重
复制代码

  • 2.4.7.4. 如果你们设计的备份系统是从数据块的级别来制作增量备份的,或是运用了源端去重机制,那么该系统在制作备份时给生产系统带来的负担就小得多了
  • 2.4.8. 有待备份的数据量在接下来的3~5年里会以什么样的速度增长
  • 2.4.8.1. 与你们构造对未来几年的规划有关
  • 2.4.8.2. 看看这些发展计划里有没有出现提到存储空间的地方
2.5. 在考虑设计方案时,规复速度对设计思路的影响要比备份速度大

  • 2.5.1. 很容易就能以每小时7TB的速度来备份整个数据中心里的数据
  • 2.5.2. 想让备份系统可以或许以每小时2.5TB的速度把数据规复到某个客户机上,就未必这么容易了
2.6. 必要与一位懂备份产品的主题专家(SME)相助,以确定这个系统所应达到的吞吐量(或者说,处置惩罚能力)​

  • 2.6.1. 每个磁盘或磁带系统的吞吐量同样有其上限,你必须把这两方面联合起来,才能明白怎样告竣本身的设计目标
  • 2.6.2. 必要把系统中的每一部分所具备的处置惩罚能力都充分发挥出来,不要浪费资源
  • 2.6.3. 必要确定它应该拥有多大的存储空间,这可以从你们约定的保留期算起
  • 2.6.4. 要求你估算未来的增长速度,必须把这个因素也考虑进来
3. 维护备份服务器上的操纵系统

3.1. 为了实现该系统,必须采用一系列实体服务器或假造服务器作为其核心部件
3.2. 备份服务器是守卫备份数据的一道门,这些备份数据是相当宝贵的资产
3.3. 如果他们可以或许获取到访问操纵系统的特权,那么就有大概提升本身对备份软件与硬件的访问权,从而借此给你们的构造造成粉碎
3.4. 为了防止他人粉碎备份数据,你必须让这些备份服务器成为整个数据中心里更新最实时且安保最严酷的服务器
4. 维护备份软件

4.1. 备份厂商经常会给它们的备份软件添加新功能
4.2. 作为备份系统的管理员,你必须尽力更新这些备份软件

  • 4.2.1. 有些更新是安全更新,必要立刻安装
  • 4.2.2. 还有一些则可以灵活处置惩罚,例如可以等到系统有时机暂时下线的时候,再去安装
  • 4.2.3. 除了要更新备份服务器上的软件,你还必须考虑本身是否安装过与该软件相配合的agent,如果有,那么这些agent也必要更新
4.3. 最恐怖的事情莫过于升级备份系统上的软件,因为新版软件有大概把原来制定的许多流程都搞乱

  • 4.3.1. 一定要给新版的备份软件做测试
5. 应对各厂商的产品之间的差别

5.1. 至少会涉及4个差别的厂商

  • 5.1.1. 备份服务器的制作商
  • 5.1.2. 备份软件的开发商
  • 5.1.3. 磁带或磁盘的制作商
  • 5.1.4. 备份数据的保管方
5.2. 全部采用磁盘保存备份副本实在太贵,所以还是会使用老式的磁带柜,在必要长期保留数据的构造里尤其容易出现这种环境
5.3. 混用各厂商产品的环境里,最大的题目就是这些产品之间会出现不兼容的现象
6. 专门用一个系统做DR

6.1. 大多数备份系统都很难满意针对规复整个数据中心的内容而设定的RTO
6.2. 许多构造都会再买一套系统,专门用来给那些执行紧张使命的系统做灾难规复(DR)
6.3. 单独购买一个系统,并采用该系统来执行DR计划
7. 专门用一个系统做电子取证

7.1. 备份是用来在系统受到损坏或粉碎之后规复该系统的,而档案则用于应对电子取证与合规方面的需求
7.2. 如果你想把暂时用不到的数据保存到成本较低的地方,那么也可以考虑将其归档(也就是将其制作成档案)​
7.3. 大多数备份系统都不适相助为档案系统使用
7.4. 单独构建一个系统做电子取证,开销不会很小,但总要低于你们手工应对电子取证请求所引发的开销
7.5. 如果你们的备份系统无法执行电子取证(其实大多数备份系统都不行)​,那么很大概会因为想要低落后续成本而决定单独购置一个电子取证系统
8. 与磁带有关的题目

8.1. 磁带机很难做性能优化

  • 8.1.1. 在许多数据保护系统里,磁带机是必备的组件,然而要想对基于磁带的备份系统做出性能优化,几乎不太大概
  • 8.1.2. 无法针对增量备份做性能优化的
  • 8.1.3. multiplexing固然能提升备份的效率,但却会低落规复时的效率
  • 8.1.3.1. 在规复时,你必须将这些备份数据全都读取出来,而且要把里面的大多数内容丢掉
  • 8.1.4. 把一套完备备份从磁盘复制到磁带差不多,而且可以或许将这两种存储设备的优势都充分发挥出来,磁盘适合充当初始的备份目标,磁带则适合用来转录已经备份好的一大批数据
  • 8.1.5. 事先把这些数据备份到磁盘,然后再将其转录到磁带上,那么至少不会出现性能题目
  • 8.1.6. 我们无法根据发送给磁带机的各种备份数据来把这些磁带机的性能给彻底调整好
8.2. 磁带大概会弄丢

  • 8.2.1. 如果你们已经采用磁盘来保存构造内部的日常备份数据了,然而有些做灾难规复时必要使用的信息依然存放在磁带上,那么这些磁带大概还是得交给“开着货车的人”(man in a van),让他把磁带运到某个所在去保管
  • 8.2.2. 磁带大概会丢失或遭窃
  • 8.2.2.1. 在制作备份时给数据加了密,那后果就没有这么严重了
  • 8.2.2.2. 把数据备份到磁带的时候,一定要加密,否则实在是太冒险了
  • 8.2.2.3. 未加密的备份磁带落到坏人手里真的很糟糕
8.3. 离站磁带的保管方也是一个风险因素

  • 8.3.1. 流程用来确保本构造总是可以或许知晓每一盘磁带目前应该位于那边
  • 8.3.2. 保管者是人,人都会出错,无论是故意还是不小心,总之,人是会出错的
9. 与磁盘有关的题目

9.1. 我们从来都没有计划去解决IT题目,我们只是要把这些题目转移到别处
9.2. 磁盘无法与备份系统断绝联系

  • 9.2.1. 磁带除了成本低廉,还有一个长处就是你很容易把它运送到离站所在,从而切断其与备份系统之间的联系
  • 9.2.1.1. 在使用磁带的那个年代,入侵者必须亲自进入保管磁带的所在,才能粉碎这些离站的备份数据
  • 9.2.2. 设置如许的屏障可以或许防止坏人删掉你们的备份数据,或者防止他们故意给这些数据加密,然后向你索要赎金
  • 9.2.3. 有人会入侵备份系统,并由此访问你们的磁盘,他会故意给这些数据加密,或者故意把它们删掉,让你将来无法执行数据规复
  • 9.2.4. 如果你是使用SaaS服务存放备份数据的,而该服务所使用的底子设施与你们本身的底子设施是完全隔开的,那么通常也可以起到防护效果
  • 9.2.4.1. 盘算机病毒与计划发起打单攻击的人,无法通过攻击你们的底子设施来顺带攻击这些备份数据
9.3. 位衰减

  • 9.3.1. 保存在磁性介质上的数据所出现的退化现象
  • 9.3.2. 磁盘里的数据块不应该存放凌驾5年,否则就有大概出现位衰减
  • 9.3.3. 唯一有效的方案就是多施加一套机制,让该机制把数据偶尔检查一遍,看看这些数据是否与从前相同
  • 9.3.4. 常见的方案是采用对象存储机制来应对这种长期存放数据的需求
  • 9.3.4.1. 如果磁性介质中的数据由于退化而变更,那么对象存储机制可以将这一状况探测出来,并予以修复
10. 其他环境

10.1. 前期必要投入大量资金购买设备

  • 10.1.1. 必须把接下来两年大概会用到的硬件也提前购买进来
10.2. 必须为有大概出现的各种状况提前设置资源

  • 10.2.1. 许多资源在备份量比力少的那些时段里会处于闲置状态
10.3. 难以扩展

  • 10.3.1. 备份系统里的组件通常都是那种只能更换而不能扩充的组件
  • 10.3.2. 备份系统必须把纳入备份范围的每一份文件,以及接受去重处置惩罚的每一个数据块,都记载在索引里面

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

小小小幸运

金牌会员
这个人很懒什么都没写!

标签云

快速回复 返回顶部 返回列表