备份数据何处放？云为衣兮霓为裳——浅谈备份介质云化

发表于 | 分类于 ，

  备份是企业IT环境中数据保护不可或缺的一个系统。传统的备份环境发展至今已经引入了很多新的元素，例如LanFree、VTL、数据消重等。随着云的兴起，备份系统的云化也逐步成为很多用户下一代备份新的选择。
  备份系统云化有很多不同的实施方案，例如云上云下部署两套同构备份做同步、云下部署代理云上进行备份管理等。今天聊一聊备份介质云化的方案，对客户云下的备份系统重构的影响最小。

备份系统概述

备份架构

  通常一个完整的备份系统由如下元素组成：

  • 服务器，在备份环境里通常含有如下不同角色的服务器：
    • 客户端：需要备份数据的服务器
    • 管理服务器：用作备份的统一管理，包括备份设备、客户端、备份策略等管理
    • 介质服务器：连接至备份设备，客户端的数据通过介质服务器写入备份设备

需要注意的是，这些服务器角色并不是互斥的，一台服务器可能充当多个角色，例如在小型环境里，通常管理服务器直接充当介质服务器；而在大型环境里，为了提升备份效率，客户端也会直接作为介质服务器将备份数据写入备份设备。

  • 备份线路：早期的备份系统一般直接使用以太网LAN作为备份线路，随着数据备份量越来越大，LAN已经不能满足备份需求，并且和业务混用LAN，对业务也会造成影响；所以存储光纤FC逐步成为备份线路的主流，这就是所谓的LanFree备份；但近些年备份系统开始引入源端消重等高级功能，FC很难实现，LAN又逐步回归占领备份领域；不过为了避免对业务影响，即使使用LAN，也建议和业务LAN分开，单独架设一个备份网络

  • 备份设备：

    • 磁带：以磁带为介质的磁带机或磁带库（TL）毫无疑问是最通用的备份设备；但磁带的先天缺陷导致其逐步被淘汰
    • 光盘：光盘刻录机或光盘塔昙花一现，问题太多，很快就淘汰了
    • 磁盘：以磁盘为介质的盘阵、虚拟带库（VTL）在现代已经成为了近线备份的主流被大多数用户接受并使用
    • 云：近些年，随着云的大规模发展，高安全性、低价格、远程访问等优势使得云在备份市场异军突起，成为新一代备份设备的主流
    • 其他：还有一些小众的备份设备例如MO等，基本没有被大众市场接受

  典型企业备份系统图如下：

  这是一个典型的D（Data）to D（Disk）to T（Tape）架构。
  磁盘设备如VTL充当一级备份，可以实现快速备份恢复，甚至在恢复的同时拉起业务，并且通过消重等技术达到数十倍于物理容量的逻辑容量。
  磁盘设备虽然有很多优势，但毕竟容量有限，并且成本较高，所以只能保存短期（以周记）的备份数据，长期（以年记）的备份数据需要转储到磁带设备上，实现低廉的长时间大容量保存。并且为了避免地域性灾害，磁带可以实现离线异地保存，提高安全性。
  而磁带本身存在先天缺陷，例如读写速度慢，没有数据校验机制，对保存环境要求严格（需要恒温恒湿）等，笔者从事备份行业时，基本每年都要遇到几个磁带数据不能恢复的案例，云替代磁带成为新的离线备份设备成为大势所趋，企业的备份系统图演化成如下架构：

  相对于磁带，云（特别是公有云）有着明显的优势：读写速度快，数据完整性有保障，先天具有离线优势，方便的远程访问可实现异地恢复等

备份设备云化方案

  备份设备云化在不同的厂商有不同的解决方案，以备份市场的排头兵EMC（已经是DellEMC，悲伤。。。）和Veritas为例：

  • DellEMC：DellEMC本身在备份专有设备市场占有率较高，所以备份设备云化的方案是通过硬件或虚拟化的备份专有设备打通云下备份环境和云上存储的通道，通常做法是将备份专有设备作为云的缓存（CloudBoost）或直接用云充当备份专有设备的二级存储（CloudTier）实现备份上云的目标。系统架构如下：

  • Veritas：Veritas以备份软件（NBU、BE）起家，虽然也在推备份一体化设备，但软件仍为其重点，解决方案也比较简单，直接将云作为备份设备，备份数据从介质服务器写入云。架构如下：

  两种方式各有优劣：
  通过备份专有设备的方式优势在于可以充分享有备份设备的各种高级功能例如源端消重，对到云端的链路要求比较低（设备到云是异步传输），云对备份管理是透明的，备份软件不用维护多个备份保留策略等；劣势在于需要专门的设备，对客户需要一笔额外投资（虚拟化的也需要买license），并且离开设备，数据恢复难度较大
  直接备份到云的优势架构比较简单，云上备份数据是独立的，可以方便的异地恢复；劣势在于，很多基于磁盘的高级功能不能实现，备份到云时虽然有本地缓存，但如果链路质量不好，缓存被打爆会造成备份失败，并且备份系统需要维护本地和云端两套数据保留策略
  具体采用什么样的备份设备云化方案要根据客户的实际业务情况。
  本次Demo测试直接备份到云的方案

备份到云测试

  测试所需要的环境：

  • 一台服务器，已经安装好NBU8.2（为了简化测试，将管理服务器、介质服务器、客户端装到同一台Windows 2016 Server），可以访问外网
  • 一个Azure账号，Global或者China都可以

    Azure环境准备

      Azure的环境准备比较简单，创建好一个存储账户即可，本次测试以Global为例，创建存储账户如下：

  区域、安全性等根据实际情况选择；需要注意的是访问层。在接下来的测试中可以看到，NBU对访问层有配置需求。

NBU配置

  在服务器打开NBU管理界面：

  点击“Config Cloud Storage Server”将云连接到NBU：

  点击下一步，NBU可以支持很多不同类型的云服务，或搜索Azure：

  选择第一项（第二项是为美国政府云准备），进入Azure配置：

  这里解释一下各选项。
  “Service Host”指定使用Azure的区域。从全球来看，除了美国政府云，Azure分为三个独立部分：AzureGlobal，AzureChina，AzureGenmany。根据实际存放备份数据的位置选择不同Host（服务的Endpoint），本Demo中使用AzureGlobal，所以选择第一项：

  “Storage Server Name”设置连接Azure的服务名，可以自定义；“Media Server Name”即介质服务器，本Demo中只有管理服务器做介质服务器，所以下拉框里只有一台供选择：

  “Access Details for Microsoft Azure Account”里填入备份数据存放的存储账户的账户名和秘钥：

  “Advanced Settings”里设置是否通过https传输，以及如果服务器不能直接访问外网时的Proxy设置：

  点击下一步，进入访问层的设置（注意，这个设置在完成后不能修改）：

  第一个选项，备份数据的访问层继承存储账户的设置
  第二个选项“ARCHIVE”，要求存储账户设置为热访问层，备份数据存入后将自动转为归档：

  这里可能会有疑惑，为什么不可以手工将数据从热层或冷层转为归档层或者通过Azure的生命周期管理定时去转？这是因为归档层的数据不能直接访问，需要先转回热层或冷层。如果在Azure端去转，NBU并不知道，需要回复时先要手工去把数据提回热层或冷层，操作较为繁琐。而让NBU自己管理，这个过程是完全自动化，简化了操作。
  这里选择第一项，点击下一步，设置备份数据块的大小，写入云端是否压缩，以及是否要用AES-256加密。如果需要加密，需要架设KMS服务器。本测试保持默认即可：

  点击下一步，忽略不加密的警告，可以看到配置的Summary：

  点击下一步完成连接到Azure的配置：

  再下一步配置成功页面，NBU已连接至Azure存储账户：

  点击下一步进入DiskPool的配置：

  点击“Add New Volumn”添加Volume，实际是向存储账户里添加容器：

  添加完成去Azure存储账户检查，发现多出一个容器：

  回到NBU，勾选这个Volume并下一步加入一个DiskPook；如果要避免和业务争抢带宽，可以在Limit I/O Streams设置带宽限制：

  接着往下确认Summary后成功创建Disk Pool：

  再下一步创建Storage Unit：

  点击下一步创建成功：

  到此，备份介质配置成功

备份测试

  准备好一个备份的源目录，以C:\Demo为例，容量3.77GB：

  点击NBU管理界面的Policies，右键点击服务器，选择“New Policy”

  为Policy起一个名字并选择用向导配置：

  因为测试目录备份，所以选择第一项即可：

  保持默认：

  这里添加客户端：

  点击Add，服务端名字写127.0.0.1，操作系统选择对应的os或者自动检查都可以：

  点击OK后，成功添加：

  这里选择备份的文件夹：

  点击Add，浏览并选择C:\Demo:

  再下一步选择备份方式（全备、增量、是否允许user发起备份等），保持默认：

  下一步，数据保留策略，保持默认：

  下一步，选择备份窗口，避免影响业务，保持默认：

  下一步，完成Policy的设置：

  现在Policies里，已经可以看到新的Policy：

  双击Policy进入设置，在Policy Storage里选择创建好的云存储：

  现在右键点击Policy，可以发起On-Demand备份（Manual Backup）：

  点击OK，开始备份：

  点击左边菜单的Activity Monitor，可以看到任务执行情况：

  挡小人变蓝，就是备份执行成功：

  双击这个activity，可以查看任务的细节：

  回到Azure的存储账户，进入NBU创建的容器里，可以看到多出了内容：

  进入文件夹里，看到的是一个一个4MB的文件，访问层继承了存储账户的热访问层，和源目录中的文件结构并不一样，这是备份软件在备份时将文件夹做成了一个“流”，并截取成一段一段，所以不用担心云端文件的安全性，即使拿到，没有备份软件的索引数据库也无法恢复：

  查看整个容器的容量，3.78GiB，因为没有启用压缩，与源目录大小基本一致:

  至此，备份完成。

归档访问层的备份测试

  再创建一个访问层为归档的云备份介质，这里选择“ARCHIVE”：

  其余保持一下，配置完成进行备份测试：

  数据写入新创建的名为“acc-stu”的Storage Unit，对应到存储账户的“achivedemo”容器：

  进入目录查看，虽然容器属于nbudemo这个默认访问层为热的存储账户，但备份的数据自动转为了归档：

  

总结

  本次测试，验证了NBU备份到云的可行性，可以看出，NBU里使用Azure Blob作为备份介质配置非常简单，对客户现有的备份环境基本没有影响，只需要在Policy修改一下备份设备即可，可以说是最简单的无痛上云方式。
  当然在具体实施时，还有一些网络、介质服务器、加密等的设置需要考虑，但对客户的长期备份数据保护，云不失为一个替代磁带的最佳解决方案。