一切皆上云，你怎忍心把备份介质留在本地？

原标题：一切皆上云，你怎忍心把备份介质留在本地？

（本文阅读时间：5分钟）

首先想问问正在阅读本文的大家：

你是什么时候开始养成备份重要数据的习惯的？

恐怕大部分人都是在真正丢失过数据之后吧？也许遭遇了病毒感染破坏，也许硬件不幸摔落或泡水，或者被梁上君子夺人所好……

那么决定备份重要数据后，你又使用了什么备份介质？软盘、光盘之类的介质？这不仅需要定期更换介质（毕竟寿命有限），还要担心未来如何读取的问题（现在想找带软驱/光驱的新电脑可不太容易）；移动硬盘/U盘之类的可移动存储设备？不仅容易丢失，而且一旦数量太多管理起来也很麻烦；

个人数据的备份就这么轻松搞定了，不过企业数据备份怎么办？那可是件更南+南的事情啊！

能否同样使用云存储作为备份介质？那首先要从企业备份系统的一些特点谈起了。

企业备份系统，复杂到让人头疼

备份是企业IT环境中数据保护不可或缺的一环。通常来说，一个完整的备份系统由如下元素组成：

服务器

在备份环境里通常含有如下不同角色的服务器：

• 客户端：需要备份数据的服务器
• 管理服务器：用作备份的统一管理，包括备份设备、客户端、备份策略等管理
• 介质服务器：连接至备份设备，客户端的数据通过介质服务器写入备份设备

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

备份线路

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

备份设备

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

因此一个典型的企业备份系统，其架构通常类似下图所示：

这是一个典型的D（Data）toD（Disk）toT（Tape）架构。其中磁盘设备（如VTL）充当一级备份，可实现快速备份恢复，甚至在恢复的同时拉起业务，并通过消重等技术达到数十倍于物理容量的逻辑容量。磁盘设备虽有很多优势，但毕竟容量有限，并且成本较高，所以只能保存短期（以周记）的备份数据，长期（以年记）的备份数据需要转储到磁带设备上，实现低廉的长时间大容量保存。并且为了避免地域性灾害，磁带可以实现离线异地保存，提高安全性。

而磁带本身也存在先天缺陷，例如读写速度慢，缺乏数据校验机制，对保存环境要求严格（需要恒温恒湿）等。笔者从事备份行业时，基本每年都要遇到几个磁带数据不能恢复的案例。

近些年，云逐渐替代磁带成为新的离线备份设备，此时企业的备份系统已经演化成如下架构：

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

备份设备云化方案

备份设备云化，这方面不同厂商有不同的解决方案，以备份市场的排头兵DellEMC和Veritas为例：

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

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

上述两种方式其实也各有优劣：

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

因此具体采用什么样的备份设备云化方案，要根据客户的实际业务情况来权衡并决定。

超长演练预警：接下来的内容，涉及备份方案详细指南，非技术群体，请直接拖到文末看小结。

直接备份到云，方案演练

下文将通过VeritasNBU“直接备份到云”的方案，来演示企业备份介质云化的可行性。本次测试用到了如下环境：

• 一台服务器，已安装好NBU8.2（为简化测试，本次实验将管理服务器、介质服务器、客户端装到同一台WindowsServer2016服务器上），可以访问外网；
• 一个Azure帐号（全球版或中国版均可）。

一、Azure环境准备

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

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

二、NBU配置

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

2.点击“ConfigCloudStorageServer”将云连接到NBU：

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

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

这里解释一下各选项。

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

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

• “AccessDetailsforMicrosoftAzureAccount”：填入备份数据存放的存储帐户的帐户名和密钥：

• “AdvancedSettings”：设置是否通过https传输，以及如果服务器不能直接访问外网时的代理设置：

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

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

这里可能一些人会有疑惑，为什么不可以手工将数据从热层或冷层转为归档层，或者通过Azure的生命周期管理定时去转？这是因为归档层的数据不能直接访问，需要先转回热层或冷层。如果在Azure端去转，NBU并不知道，需要回复时先要手工去把数据提回热层或冷层，操作较为繁琐。而让NBU自己管理，这个过程是完全自动化，简化了操作。

6.这里选择第一项，点击下一步，设置备份数据块的大小，写入云端是否压缩，以及是否要用AES-256加密。如果需要加密，需要架设KMS服务器。本测试保持默认即可：

7.点击下一步，忽略不加密的警告，可以看到配置的摘要信息

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

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

10.点击下一步进入DiskPool配置：

11.点击“AddNewVolumn”添加Volume，实际是向存储帐户里添加容器：

12.添加完毕后检查Azure存储帐户，发现多出一个容器：

13.回到NBU，勾选这个Volume并点击下一步加入DiskPook；如果要避免和业务争抢带宽，可以在LimitI/OStreams设置带宽限制：

14.接着往下确认摘要后成功创建DiskPool：

15.再下一步创建StorageUnit：

16.点击下一步创建成功：

至此，备份介质配置成功。

三.备份测试

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

2.点击NBU管理界面的Policies，右键点击服务器，选择“NewPolicy”：

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

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

5.保持默认设置：

6.这里添加客户端：

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

8.点击OK后，成功添加：

9.这里选择备份的文件夹：

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

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

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

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

14.下一步，完成Policy的设置：

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

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

17.右键点击Policy，可以发起On-Demand备份（ManualBackup）：

18.点击OK，开始备份：

19.点击左边菜单的ActivityMonitor，可以看到任务执行情况：

20.当策略最左侧的小人变为蓝色，意味着备份执行成功：

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

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

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

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

至此，备份完成。

四、归档访问层的备份测试

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

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

3.数据写入新创建的名为“acc-stu”的StorageUnit，对应到存储帐户的“achivedemo”容器：

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

总结

本次测试验证了NBU备份到云的可行性，可以看出，NBU里使用AzureBlob作为备份介质配置非常简单，对客户现有的备份环境基本没有影响，只需要在Policy修改一下备份设备即可，可以说是最简单的无痛上云方式。

当然在具体实施时，还有一些网络、介质服务器、加密等的设置需要考虑，但对客户的长期备份数据保护，云不失为一个替代磁带的最佳解决方案。

4月17-18日，首届MicrosoftOnlineTechForum微软在线技术峰会将在线上正式拉开帷幕！微软将会围绕“数字化转型加速度”为主题，以自身技术产品和行业实践为引，希望能够加速行业内的数字化进程，引领业界未来数字生态的趋势走向，即可查看更多精彩。

1