0.摘要
数据备份作为保护信息数据安全的重要措施；当系统受到破坏时，数据备份是可以将损失降低到最小的行之有效的办法。数据备份的目的是将整个系统的数据和状态保存下来，这种方式不仅可以挽回硬件设备带来的损失，也可以挽回系统错误和人为恶意破坏的损失。
1.背景
通过上次存储设备损坏造成生产宕机这一事故发现，主要原因有两方面：一方面有部分生产虚拟机建立在存储设备上，而备份机有数据拓展盘也存放在存储设备上，导致出现故障后，这部分生产虚拟机备份数据丢失不能恢复，另一方面是日常备份对象不齐全，备份进度与备份状态不透明、信息上传不及时，因而上层领导不能准确掌握备份工作情况。
关键业务数据的保护势在必行。以这次生产故障为教训，公司决定重新设计整个网络的备份系统和相关的备份和灾难恢复策略，科学规划，合理实施，达到可以安全备份和快速恢复业务数据、工作进展及时汇报上传的水平，从而提高整个企业的数据安全级别。
2.备份需求
实际生产中，公司需要备份的是 ESXI 242 和 ESXI 161 上的做生产用途的虚拟机，包括windows虚拟机和Linux虚拟机，如图1。
图1.生产备份对象
具体要求是：
（1）备份要适应实际：以现有的硬件设备进行备份设计，尽可能减少成本输出；
（2）整机备份：既可以及时恢复虚拟机的系统状态，又可以恢复业务数据，windows虚拟机要具体到盘符或者文件恢复；
（3）分开进行备份与存放备份数据：避免同时宕机丢失数据的危险；
（4）内网备份：最大程度降低网络影响与减少时间成本；
（5）任务可追踪、信息传递要及时：要求可以实时看到具体任务规划与备份进度，备份结束要求有信息发送告知。
3.恢复要求
根据实际生产系统虚拟机备份定义合理的恢复点目标（RPO）和恢复时间目标（RTP），结合与设定的RPO和RTO设计合理的备份调度周期，合理的设计各个系统的备份时间。最后，最关键的就是备份恢复的相关测试，设计相应的制度，定期对备份恢复进行演练。
3.1 灾难恢复能力指标
RPO:（Recovery Point Obejective，恢复点目标）是指业务系统所允许的在灾难过程中的最大数据丢失量，用来衡量容灾系统的数据冗余备份能力。如图2所示：
图2. 恢复点目标RPO
RTO:（Recovery Time Obejective，恢复时间目标）是指信息系统从灾难状态恢复到可运行状态所需的时间，用来衡量系统的业务恢复目标。如图3所示：
图3. 恢复时间目标RTO
3.2 RPO与RTO指标
3.2.1备份针对RPO要求：
根据RPO数据丢失程度，可以分为6个数据冗余级别，如表1：
表1. 数据冗余级别
备份方案的设计决定了备份的调度周期与备份时间，也决定了RTO还原的最大数据丢失程度。因此，针对公司生产与非生产虚机，要求如下：
（1）生产—数据月变化量大的虚拟机：例如财务系统，要求月初/月末二级恢复，月中四级恢复；
（2）生产—数据月变化量不大的虚拟机：例如：FTP文件共享、NFS、要求四级恢复；
（3）测试类的虚拟机：例如研发类虚机SVN、NFS要求四级恢复；
（4）其他类虚拟机：例如门禁要求四级恢复;
（5）部分不能做增量备份的虚机：例如研发WAF、dockerRegistry、WIKI、SVN要求6级恢复。
3.2.2恢复针对RTO要求：
根据RTO恢复时间快慢，可以分为六个数据恢复级别，如表2：
表2. 数据恢复级别
备份的虚拟机里面，有的是生产必须类，有的是公司内部环境必须类，有的是测试必须类，和其他类。对于不同类的虚拟机有不同的恢复要求，分别是：
（1）生产必须类虚拟机：例如官网、财务系统虚拟机要求一级恢复；
（2）公司内部环境必须类虚拟机：例如域账号、DNS、NTP、门禁虚拟机要求二级恢复；
（3）测试必须类虚拟机：例如自研类虚拟机要求二级恢复；
（4）其他类虚拟机：例如FTP文件共享、SVN、NFS类要求三级恢复。
但是，为了不影响公司上产与整体员工的工作，除硬件条件外，要求所有虚拟机尽可能在12小时内恢复全部数据，尽最大可能还原故障前的环境。
4.架构
4.1整体系统架构
图4.系统整体架构图
系统结构说明：
（1）备份服务器（BE）
BackupExec服务器是备份虚拟机，分别安装在ESXI 242 和 ESXI 161 上独立运行，可用来备份Windows、Linux服务器。专用备份服务器对提高备份效率更为有利，管理起来也更为方便；备份时不占用应用服务器系统资源，不会影响应用业务系统的运行。
BackupExec服务器上安装Microsoft 评估和部署工具包(ADK)。它为灾难恢复磁盘(SDR)中可用的功能提供有限支持。
备份代理Backup Exec agent for Windows
将客户端 Backup Exec agent for Windows 有选择的安装在需要备份的 Windows 服务器上，通过网络连接 BackupExec 服务器，可以实现在单台备份 Virtual Machine 后，还原数据精确到具体盘符和文件。
备份代理Backup Exec agent for Linux
将代理 Backup Exec agent for Linux 有选择的安装在需要备份的 Linux 服务器上，通过网络连接 BackupExec 服务器，可以实现在单台备份 Linux Virtual Machine。
（2）备份对象
ESXI 242 和 ESXI 161 上的相关服务器是BackupExec服务器主要的备份对象,包括：生产类虚拟机、生产测试类虚拟机、公司内部必须类虚拟机。ESXI 242 上的备份服务器（BE）备份 ESXI 161上的服务器，ESXI 161 上的备份服务器（BE）备份 ESXI 242 上的服务器，但双方 BackupExec服务器不互备，避免了互备导致存储循环递增带来的问题。将备份服务器与业务主机分离开来，既便于管理，也提高了备份数据的安全性。
（3）存储
备份数据以备份 BackupExec 服务器所在的 ESXI Date Stor为存储对象。
可以将备份服务器与业务服务器分离开来，以便于管理，也提高了备份数据的安全性;备份时不占用应用服务器系统资源，不会影响应用业务系统的运行；专用备份服务器对提高备份效率更为有利，管理起来也更为方便。
（4）网络
存储数据通过局域网将备份传输到对方 ESXI 上的BackupExec服务器。
采用内网网络备份模式，BackupExec 可以直连 ESXI 获取批量需要的应用服务器所有数据，也可以单独连接应用服务器由备份代理将数据打包，通过TCP/IP网络传到BackupExec服务器，最终完成到数据存储备份，具有实现简单、灵活、易管理等优点，不需要占用业务网络的带宽，即减轻了业务网络的压力，也有利于备份速度的提高。
4.2备份原理
（1）BE 1 安装在 ESXI 242 上， BE2 安装在 ESXI 161上；
（2）BE1 通过备份 ESXI 161 上的应用服务器整机数据存放到 ESXI 242上，BE2 备份 ESXI 242 上的应用服务器整机数据存放到 ESXI 161上；
（3）当 ESXI 242 上的应用服务器数据丢失或者系统损坏，可以使用 BE2 通过 vCenter 服务器把相应盘符、文件数据还原到原 Virtual Machine系统，甚至是把整台服务器系统数据还原到 ESXI 242上；同理，当 ESXI 161上的应用服务器数据丢失或者系统损坏，可以使用 BE1 通过 vCenter 服务器把相应盘符、文件数据还原到原 Virtual Machine系统，甚至是把整台服务器系统数据还原到 ESXI 161上。
如图5所示。
图5. 备份原理
5、备份系统设计
5.1备份系统的结构
一个科学和完整的备份系统包括以下的组成部分：
• 备份管理软件
• 执行备份的硬件和介质
• 备份策略
• 灾难恢复计划
如图6所示。
图6. 备份系统的结构
5.2备份管理软件
VERITAS Backup Exect提供了一种高性能、易于使用且灵活有效的网络备份解决方案。该方案独特的Backup Exec Assistant简化了启动、系统配置、作业调度和其它任务，提高了操作效率。Backup Exec 带有众多可用选项与代理软件，可支持不断扩展的网络和不断变化的配置。由于Backup Exec能够保护关键任务数据。与全部系列的高性能代理和选件并用，Backup Exec具有快速保护台式电脑、笔记本电脑和服务器数据的易用性和灵活性，简化网络日常管理，大幅度降低了系统拥有成本。
本次备份方案选择的是 Backup Exec 20.5 版本，具备邮件发送功能，可以附带详细记录，即使不登录也可以知道备份与还原结果。
5.3备份的硬件和介质
执行备份的存储硬件的质量与性能在整个备份过程中是至关重要的，它是能否进行高质量备份的关键所在。目前用于备份的存储主要有磁盘设备和磁带设备。磁盘设备具有快速的读写和快速搜索能力，适合于快速的数据备份（<3T），但不适合数据的较长期离线保存；而磁带设备具有大容量、每兆字节价格低和便于离线存放的特征，适合于大数据量的备份，但是执行备份和恢复的速度相对较慢。
介质是数据的负载物，可以是磁带也可以是硬盘。
根据公司现有的硬件设施，结合目前备份的服务器规模——每台 ESXI 上需要备份的服务器数量不到20台。采用ESXI 磁盘设备作为备份存储介质比较合适目前的需求，可以满足对存储设备容量和备份速度的需要。
(结合Backup Exec目前备份所占用空间预算)
目前ESXI 242 磁盘空余空间：> 12T
目前ESXI 161 磁盘空余空间：> 3.5T
5.4 备份策略
当前最重要的是备份ESXI 242，因此，以ESXI 242为例：
5.4.1 ESXI 242 上的服务器
表3. ESXI 242当前服务器
5.4.2 需要备份的服务器
表4. ESXI 242需要备份的服务器
5.4.3备份测试
完全备份：耗时 <9h 消耗空间 1.00-1.10TB
增量备份：耗时 <3h 消耗空间90-95GB （部分服务器不能实现增量备份）
5.4.4完全备份还原耗时
表5. 服务器还原耗时
5.4.5备份方案
根据实际需求，备份设计如下：
（1） 单次完全备份
（2） 下面这四台虚机经过多次测试均无法实现增量备份。其中，
第 1 台虚机是备用的虚机，平时不启动，每月无数据变化。
第 2~4 台虚机是研发部门的，经过沟通可以不做增量备份。
因此，这四台虚机只在月底做完全备份，不做增量备份。
增量备份：每月29号晚上23:59开始
表6. 单次完全备份服务器
（2）月中增量备份，月底完全备份
增量备份：每月15号晚上23:59开始
完全备份：每月30号晚上23:59开始
表7. 月中增量备份，月底完全备份服务器
（3）自定义备份
财务系统备份设计：
增量备份：每月7、20号晚上23:59开始
完全备份：每月30号晚上20:00开始
表8. 自定义备份服务器
（4）时间表
表9. 每月备份时间表
5.5灾难恢复计划
5.5.1 应用服务器宕机
（1）vCenter 宕机
经过测试，目前不主张备份vCenter服务器。虽然Backup Exec服务器备份可以通过单台Virtual Machine、ESXI、vCenter这三种方式进行备份，但是在 VMware 6.7 版本上测试发现，还原必须通过 vCenter 还原（灾难恢复磁盘除外）。因此，即使备份了vCenter 服务器，当vCenter宕机了，不能通过 BackupExec 进行还原。
如何解决：测试环境上也有一台 vCenter 服务器，如果生产上的 vCenter 宕机了，可以把 ESXI 242 临时加入 测试环境 vCenter 进行托管，经测试，BackupExec可以正常还原。另一种方法是，现有的生产 vCenter 服务器是在 ESXI 161上，在 ESXI 搭建另一台 vCenter 服务器在ESXI 242上。当现有的vCenter宕机，登录 ESXI 启用另一台vCenter 服务器，把 HOST 加入即可正常使用，不影响 BackupExec 还原。
（2）BackupExec宕机
当 BackupExec 宕机，根据最初的设计方案，备份的服务器数据存放到与其本身服务器不同的 ESXI 存储上，避免服务器数据与备份数据同时出现故障丢失的风险。因此，当 BackupExec 宕机，此时的备份对象服务器应当还在正常运行。建议：在最短的时间内重新搭建一台新的 BackupExec 服务器，然后进行完全备份。
（3）其他Virtual Machine宕机
当其他业务Virtual Machine宕机时，如果不能恢复运行，可以采用 BackupExec 进行还原。可以选择保留故障服务器以备后期检查。
还原要求 ESXI 必须分配和原故障服务器相等的存储空间、内存、CPU，同时还原可以选择还原至原路径或者其他ESXI 服务器。可能影响还原速度的因素有：内网带宽、ESXI 磁盘 I/O性能。
需要注意的是，一些做了许可验证或者从磁盘识别码上做了限制的服务器，即使还原成功也需要重新进行识别验证。
5.5.2 ESXI宕机
当现有的 ESXI 因故障导致宕机，可以以“还原至其它路径”形式或者灾难恢复磁盘还原服务器至其他 ESXI上。建议采用以ESXI 备份的形式进行服务器还原，因为灾难恢复磁盘不仅需要做灾难映像iso文件，还需要下载到本地，然后上传到相应 ESXI OS目录，极其消耗时间，而且灾难恢复磁盘只针对 Windows 服务器，Linux 服务器无法制作灾难恢复磁盘。
以ESXI 备份的形式进行服务器还原，需要新的 ESXI 代替故障 ESXI 。如果现有的 ESXI 主机没有足够的存储空间或者内存、CPU，可以考虑按照不同的 ESXI 可用资源把备份的服务器分别还原到多台 ESXI 上。改变路径还原每次只能还原一台服务器，不能一次还原多台。
6.报表
为了使工作规范化，流程化，每次备份结束后，不论备份结果是否成功，需要在第二天及时把报表以邮件的形式发送给领导，以便让领导掌握备份工作详情。如下表10：
表10. 备份月表
原创，转载请注明出处
2020-07-30