读数据保护:工作负载的可恢复性09磁盘备份方案

打印 上一主题 下一主题

主题 797|帖子 797|积分 2391


1. 用磁盘给磁带机做缓存

1.1. 对于云端来说,并没有D2D2T(Disk-to-Disk-to-Tape,从磁盘到磁盘再到磁带)之类的说法
1.2. 大多数备份都是增量备份
1.3. 每秒钟只会产生几个到几十个MB的数据,然而磁带机所要求的速度则是每秒钟几百个MB,它们至少要达到这样的速度才能顺畅地运行

  • 1.3.1. 假如磁带机的理想速度是每秒700MB,而你的备份流程每秒只能产生10MB的数据,那么磁带机与备份流程都会出状况
1.4. 没人关心你能不能备份,他们只看你能不能从中恢复数据
2. 备份系统中利用磁盘

2.1. 把一些磁盘放在磁带柜的前端,让它充当磁带机的缓存

  • 2.1.1. 根据每晚所能产生的最大备份量来购买充足多的磁盘
  • 2.1.2. 由于这些磁盘只是用来给磁带机做缓存的,因此最坏的情况只不外就是由于磁盘受损而丢失昨天晚上所做的那个备份
2.2. SATA、SAS与SSD的性能与可靠水平各不相同,SAS比SATA好,SSD比SAS好
2.3. 一定要考虑到是否需要做即时恢复,也就是说,你需不需要直接把备份挂载成虚拟机
2.4. 假如要做即时恢复,那么大概可以考虑多花一些钱,购买SAS或SSD来给磁带机做缓存
2.5. 标准的磁盘阵列应该比目的去重设备自制

  • 2.5.1. 不需要购买目的去重系统的
  • 2.5.2. 不会产生与利用目的去重系统有关的一些开销
  • 2.5.3. 只是用磁盘暂时存放一些数据,让它们能够高速地发给磁带机而已
  • 2.5.4. 每个备份流程都可以按照各自的速度把数据写入磁盘阵列,而不会影响到其他的备份流程
2.6. 把所有的备份都做完之后,将它们复制到两套磁带内里,一套保存在主站的磁带柜中,另一套转移到别处
2.7. 末了一步就是要在新做的备份即将进入磁盘之前,让磁盘中最旧的那个备份过期(也就是将其删掉)​

  • 2.7.1. 尽量让每个备份都在磁盘里待得久一些,因为此中的某个备份大概会在恢复数据的过程中用到
  • 2.7.2. 精良的备份系统应该能够主动执行这个让备份过期的处置惩罚,它们会在你正要制作今天晚上的这个备份时,把最老的那个备份删掉
2.8. 用磁盘做备份缓冲(disk staging),能够解决备份数据的传入速度与磁带机的速度不一致的题目

  • 2.8.1. 恢复数据并没有太大帮助,除非你的磁盘能够容纳一个完全备份以及根据这个完全备份所制作的一系列增量备份
  • 2.8.2. 磁盘缓存的主要优势并不在于它能帮我们更顺遂地恢复数据,而在于它能够让我们用较低的成本,轻松地实现出一种能够将数据顺遂写入磁带的机制
  • 2.8.3. 让我们能够相沿目前的磁带柜系统与备份软件,我们只需要购置几块价格相对低廉的磁盘,就可以让磁带柜与备份软件对接得更加顺畅
3. D2D2T

3.1. D2D2T(Disk-to-Disk-to-Tape,从(有待保护的系统的)磁盘到(备份系统的)磁盘再到(磁带柜内里的)磁带)​
3.2. 所购买的磁盘不是用来暂时生存一个晚上的备份量,而是用来正式保存备份数据,这意味着你可以利用去重技术,让磁盘所要生存的数据少一些,这样就能够少买几块磁盘
3.3. 所购置的磁盘至少要能够生存一个备份周期里的数据量(也就是一个完全备份与一系列基于这个完全备份所制作的增量备份)​
3.4. 应该把所有的备份先发送到生存去重数据的磁盘,然后再从磁盘复制到磁带

  • 3.4.1. 生存去重数据的磁盘,就是你在执行恢复时首选的数据泉源
  • 3.4.2. 只有在无法通过该磁盘恢复数据时,才考虑从磁带内里恢复
  • 3.4.3. 磁带只用来生存离站的备份副本,这些副本在磁带上存留的时间大概比在磁盘上更长
  • 3.4.4. 只会制作一份磁带情势的副本,并将其存放到别处
  • 3.4.5. 副本只用来应急,大家都不想遇到真正需要利用它的情况,但万一遇到了,它还是管用的
3.5. 跟这个方案相搭配的去重技术,通常是目的去重技术

  • 3.5.1. 在只能购买一个去重设备的前提下,还是利用目的去重比较方便
3.6. 利用源端去重时必须注意一个题目,就是某些系统大概会把已经去重的数据直接复制到磁带内里
3.7. 将去重数据存放在磁带上,意味着恢复一份文件大概要用到好几盘磁带,因为必须把分散在那些磁带里的数据联合起来才能得到完整的文件

  • 3.7.1. 磁带比较自制,我们不值得为了节省磁带而把经过去重处置惩罚的数据生存到上面,那样会给恢复工作造成很大困难,你必须先把这些数据所缺失的内容弥补返来,然后才能恢复
  • 3.7.2. 需要用磁带做恢复,通常意味着已经无法用其他方式来做恢复了,在这种情况下假如还要先把缺失的数据弥补返来,那会更加忙乱
4. D2D2D

4.1. 可以彻底不用磁带,而是完全采用磁盘来构建备份与恢复系统,这叫作D2D2D(Disk-to-Disk-to-Disk,从(有待保护的系统的)磁盘到(备份系统的)磁盘再到(位于别处的另一套)磁盘)​
4.2. 需要采用某种去重技术给备份去重,并把它生存到磁盘系统上,然后,你需要将磁盘系统里生存的这些已经去重的备份复制到另一个磁盘系统,这次复制所涉及的去重技术,与刚开始备份时所采用的去重技术,应该是同一个厂家提供的
4.3. 假如利用目的去重系统,那么这个复制备份数据的过程可以由去重设备来做,也可以由备份软件来做
4.4. 不需要在备份流程里专门对这个复制的过程做配置或管理,你只需要安排两个设备,并让此中一个把备份复制到另一个上面
4.5. 不需要借助某个服务提供商,就可以制作出在场备份与离场备份
4.6. 让设备来管理这个复制备份数据的过程,其弊端在于:备份软件并不知道这个备份还有一个副本生存在别处

  • 4.6.1. 让设备来管理复制过程,还意味着这个过程对备份软件来说是“不可见的”,
  • 4.6.2. 将去重之后的备份照原样复制过去,假如它不清楚这一点,那么有大概会先把备份里缺失的内容弥补返来,然后再复制
  • 4.6.3. 源端去重,那就无须担心这题目了,这也是源端去重的另一项优势
  • 4.6.3.1. 备份软件清楚这些数据是已经去重的备份数据,只需要直接复制到别处就好,不需要先将此中缺失的内容弥补返来
4.7. 让备份软件来管理这个复制备份数据的过程,还有一个好处就是可以针对不同的设备指定不同的保存期
5. D2C

5.1. D2C(Direct-to-Cloud,直接到云)​,这种方案需要配合源端去重技术
5.2. 所有的备份都放在备份客户端去重,然后把此中互不重复的chunk直接发送到云端
5.3. 利用源端去重意味着你可以在任何地方做备份,而不像采用目的去重,还必须在那个地方安设一个硬件才行
5.4. 最大缺陷在于,如何处置惩罚首次备份的数据以及那些数据量比较大的恢复工作
5.5. 如何处置惩罚第一次备份,这种备份也称为initial seed(初始种子)

  • 5.5.1. 对于源端去重来说,增量备份所产生的数据量通常还不到有待备份的那个数据集的百分之一,因此,向云端传输这种日常的增量备份对带宽并没有多高的要求
  • 5.5.2. 第一次备份必须把所有的东西都备份下来,因此按照你们目前的网速来说,大概要花好长时间才能把数据传过去
  • 5.5.3. 很多D2C的备份产物与服务,都支持通过物流来传输首次备份的数据
  • 5.5.3.1. 可以把这次备份的数据放在一个便携设备里,寄给云平台的提供商
5.6. 云端做DR(劫难恢复)
6. D2D2C

6.1. 一种只需要利用磁盘的方案,叫作D2D2C(Disk-to-Disk-to-Cloud,从磁盘到磁盘再到云)​,它是先把数据备份到本组织本身的磁盘系统内里,然后再将此中的某些或全部备份生存到云端
6.2. D2D2C跟D2C之间的区别在于,云端仅是用来存放备份副本或旧备份的次要场所,放在本组织内里的这个备份,才是主要的备份
6.3. D2D2C方案通常会由那些传统的备份厂商提供,他们主要是把经过去重的备份数据复制到客户本身的磁盘系统内里,云端仅是生存应急副本的地方

  • 6.3.1. 把本来应该放在别处的备份副本放在了云端而已
6.4. 通常会把备份复制到对象存储系统(例如S3)​,而且通常会把此中已经删掉的重复内容弥补返来
6.5. 假如你想把备份数据放在本组织本身的系统里,以便将来能够快速恢复数据,而把云端只当成能够生存另一套备份且开销比较低的地方(也就是说,你并不想从云端做劫难恢复)​,那么将备份复制到对象存储系统中就是比较符合的做法

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

本帖子中包含更多资源

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

x
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

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

本版积分规则

不到断气不罢休

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

标签云

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