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

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. 如果你想把备份数据放在本组织自己的系统里，以便将来能够快速恢复数据，而把云端只当成能够保存另一套备份且开销比较低的地方（也就是说，你并不想从云端做灾难恢复）​，那么将备份复制到对象存储系统中就是比较合适的做法