我们的土耳其客户要求我们为数据中心正确配置备份。 我们正在俄罗斯进行类似的项目，但在这里，故事更多地是关于研究如何做到最好的故事。
鉴于：有一个本地S3存储，还有一个Veritas NetBackup，它已经获得了新的高级功能，现在可以通过重复数据删除支持将数据移动到对象存储中，并且该本地存储中的可用空间存在问题。
目标：做好一切，使备份存储过程既快速又便宜。
实际上，在此之前，在S3中，所有内容都只是文件，而这些文件都是对关键数据中心计算机的完整转换。 并不是说它已经非常优化，而是一切从一开始就起作用。 现在是时候弄清楚并正确地做。
在图中，我们得出以下结论：
如您所见，第一次备份的执行速度很慢（70 Mb / s），而同一系统的后续备份则要快得多。
实际上，关于那里的功能还有更多的细节。
那些准备阅读半页转储文件的备份日志充满重新扫描
2018年12月18日12:09:43 PM-信息bpbkar（pid = 4452）加速器从14883994624字节中向服务器发送了14883996160字节，优化为0.0％
2018年12月18日12:10:07 PM-信息NBCC（pid = 23002）StorageServer = PureDisk_rhceph_rawd：s3.cloud.ngn.com.tr; 报告=用于（NBCC）的PDDO统计信息（已使用多线程流）：已扫描：14570817 KB，已发送CR：1760761 KB，已通过FC发送CR：0 KB，重复数据删除：87.9％，已禁用缓存
已满
2018年12月18日12:13:18 PM-信息bpbkar（pid = 2864）加速器将14884060160字节中的181675008字节发送给服务器，优化了98.8％
2018年12月18日12:13:40 PM-信息NBCC（pid = 23527）StorageServer = PureDisk_rhceph_rawd：s3.cloud.ngn.com.tr; 报告=（NBCC）的PDDO统计信息：已扫描：14569706 KB，已发送CR：45145KB，已通过FC发送CR：0KB，重复数据删除：99.7％，已禁用缓存
增量式
2018年12月18日12:15:32 PM-信息bpbkar（pid = 792）加速器从14726108160字节中向服务器发送了9970688字节，优化了99.9％
2018年12月18日12:15:53 PM-信息NBCC（pid = 23656）StorageServer = PureDisk_rhceph_rawd：s3.cloud.ngn.com.tr; 报告=（NBCC）的PDDO统计信息：已扫描：14383788 KB，已发送CR：15700 KB，通过FC已发送CR：0 KB，重复数据删除：99.9％，已禁用缓存
已满
2018年12月18日12:18:02 PM-信息bpbkar（pid = 3496）加速器向服务器发送了14884093952字节中的171746816字节，优化率为98.8％
2018年12月18日12:18:24 PM-信息NBCC（pid = 23878）StorageServer = PureDisk_rhceph_rawd：s3.cloud.ngn.com.tr; 报告=（NBCC）的PDDO统计信息：已扫描：14569739 KB，已发送CR：34120 KB，已通过FC发送CR：0 KB，重复数据删除：99.8％，已禁用缓存
有什么问题
客户希望尽可能多地备份并尽可能便宜地存储。 将它们最好地存储在S3类型的对象存储中是很便宜的，因为按每兆字节的维护成本，它们是最便宜的，您可以在合理的时间内从那里进行回滚。 当有很多备份时，它变得不是很便宜，因为大多数存储都被相同数据的副本占用。 就土耳其同事的HaaS而言，存储密度可以提高约80-90％。 显然，这特别适用于它们的细节，但是我绝对可以指望至少有50％的重复数据。
为了解决该问题，主要供应商一直在Amazon S3上建立网关。 如果它们的所有方法都支持Amazon API，则它们与本地S3兼容。 在土耳其的数据中心，我们的S3以及俄罗斯的T-III“压缩机”都完成了备份，因为事实证明这样的工作计划对我们来说是很好的。
我们的S3与Amazon S3中的备份方法完全兼容。 也就是说，所有支持这些方法的备份工具都允许您“开箱即用”地将所有内容复制到这样的存储中。
Veritas NetBackup提供了CloudCatalyst功能：
也就是说，在需要备份的计算机和网关之间，有一台中间的Linux服务器，CPC代理的备份流量通过该服务器传递，并且在将它们传输到S3之前即时进行重复数据删除。 如果以前有30个压缩大小为30 GB的备份，现在（由于计算机的相似性），它们的容量已缩小了90％。 重复数据删除引擎的用法与使用Netbackup存储在常规磁盘上的用法相同。
这是登台服务器之前发生的事情：
我们进行了测试并得出结论，当在我们的数据中心中实施时，这可以为我们和客户节省S3存储中的空间。 作为商业数据中心的所有者，我们当然要对占用的空间收取费用，但对于我们来说仍然是非常有利可图的-因为我们开始从软件中更具扩展性的位置上赚钱，而不是从铁板上出租。 好吧，这是内部成本的降低。
日志228作业（0排队0活动0等待重试0暂停0不完整228完成-选择13
（已应用过滤器[13]）
作业ID类型状态状态详细信息状态作业策略作业计划客户端媒体服务器启动时间逝去时间结束时间存储单元尝试操作千字节文件路径名％完成（估计）作业PID所有者复制父作业ID KB /秒活动开始活动活动机器人库配置文件会话退出数据移动的ID介质主机外类型主优先级重复数据删除率传输加速器优化实例或数据库共享主机
-1358快照完成0 VMware-NGNCloudADC NBCC 2018年12月18日12:16:19 PM 00:02:18 2018年12月18日12:18:37 PM STU_DP_S3 _ ****备份1100％根1358 2018年12月18日12 ：16:27 PM 00:02:10 Instant Recovery Disk Standard WIN-*********** 0
1360完成备份0 VMware Full NGNCloudADC NBCC 2018年12月18日12:16:48 PM 00:01:39 2018年12月18日12:18:27 PM STU_DP_S3 _ ****备份1 14,535,248 149654 100％23858根1358 335,098 12月18日，2018 12:16:48 PM 00:01:39 Instant Recovery Disk Standard WIN-*********** 0 99.8％99％
1352快照完成0 VMware-NGNCloudADC NBCC 2018年12月18日12:14:04 PM 00:02:01 2018年12月18日12:16:05 PM STU_DP_S3 _ ****备份1100％根1352 2018年12月18日12： 14:14 PM 00:01:51 Instant Recovery Disk Standard WIN-*********** 0
1354完成备份0 VMware增量NGNCloudADC NBCC 2018年12月18日12:14:34 PM 00:01:21 2018年12月18日12:15:55 PM STU_DP_S3 _ ****备份1 14,380,965 147 100％23617根1352 500,817 12月18日，2018 12:14:34 PM 00:01:21 Instant Recovery Disk Standard WIN-*********** 0 99.9％100％
1347快照完成0 VMware-NGNCloudADC NBCC 2018年12月18日12:11:45 PM 00:02:08 2018年12月18日12:13:53 PM STU_DP_S3 _ ****备份1100％根1347 2018年12月18日12： 11:45 PM 00:02:08 Instant Recovery Disk Standard WIN-*********** 0
1349完成备份0 VMware Full NGNCloudADC NBCC 2018年12月18日12:12:02 PM 00:01:41 2018年12月18日12:13:43 PM STU_DP_S3 _ ****备份1 14,535,215 149653 100％23508根1347 316,319 12月18日，2018 12:12:02 PM 00:01:41 Instant Recovery Disk Standard WIN-*********** 0 99.7％99％
1341快照完成0 VMware-NGNCloudADC NBCC 2018年12月18日12:05:28 PM 00:04:53 2018年12月18日12:10:21 PM STU_DP_S3 _ ****备份1100％根1341 2018年12月18日12：下午05:28 PM 00:04:53 Instant Recovery Disk Standard WIN-*********** 0
1342完成备份0 VMware Full_Rescan NGNCloudADC NBCC 2018年12月18日12:05:47 PM 00:04:24 2018年12月18日12:10:11 PM STU_DP_S3 _ ****备份1 14,535,151 149653 100％22999根1341 70,380 12月18日，2018 12:05:47 PM 00:04:24 Instant Recovery Disk Standard WIN-*********** 0 87.9％0％
1339快照已完成150 VMware-NGNCloudADC NBCC 2018年18月18日11:05:46 AM 00:00:53 2018年12月18日11:06:39 AM STU_DP_S3 _ ****备份1100％根1339 2018年12月18日11： 05:46 AM 00:00:53 Instant Recovery Disk Standard WIN-*********** 0
1327快照完成0 VMware-*******。********。Cloud NBCC 2018年12月17日12:54:42 PM 05:51:38 2018年12月17日6:46:20 PM STU_DP_S3 _ ****备份1100％根1327 2018年12月17日12:54:42 PM 05:51:38 Instant Recovery Disk Standard WIN-*********** 0
1328备份完成0 VMware完整*******。********。云NBCC 2018年12月17日12:55:10 PM 05:29:21 2018年12月17日6:24:31 PM STU_DP_S3 _ ****备份1 222,602,719 258932 100％12856根1327 11,326 2018年12月17日12:55:10 PM 05:29:21 Instant Recovery Disk Standard WIN-*********** 0 87.9％ 0％
1136快照完成0 VMware-*******。********。Cloud NBCC 2018年12月14日4:48:22 PM 04:05:16 2018年12月14日8:53:38 PM STU_DP_S3 _ ****备份1100％根1136 2018年12月14日下午4:48:22 04:05:16 Instant Recovery Disk Standard WIN-*********** 0
1140备份完成0 VMware Full_Scan *******。********。Cloud NBCC 2018年12月14日下午4:49:14 03:49:58 2018年12月14日晚上8:39:12 STU_DP_S3 _ ****备份1 217,631,332 255465 100％26438根1136 15,963 2018年12月14日4:49:14 PM 03:49:58 Instant Recovery Disk Standard WIN-*********** 0 45.2％ 0％
加速器使您可以减少来自代理的流量，因为 仅传输数据更改，也就是说，即使完全备份也不会全部倒入，因为媒体服务器会从增量备份中收集后续的完全备份。
中间服务器具有自己的存储库，该存储库在其中写入数据的“缓存”并为重复数据删除奠定基础。
在完整的体系结构中，它看起来像这样：
- 主服务器位于云中，可管理配置，更新等。
- 就网络可用性而言，介质服务器（中间* nix机器）应位于距离冗余系统最近的位置。 在这里，备份将从所有冗余计算机中删除重复数据。
- 冗余计算机上的代理通常仅将介质中未存储的内容发送到介质服务器。
这一切都从完整扫描开始-这是完整的完整备份。 此时，媒体服务器将对所有内容进行删除，重复数据删除并将其传输到S3。 到媒体服务器的速度较低，从此为较高。 主要限制是服务器的处理能力。
从所有系统的角度来看，以下备份是完整的，但实际上，它类似于合成的完整备份。 也就是说，实际传输和记录到介质服务器只是那些以前在VM备份中尚未看到的数据块。 而且，仅将那些哈希不在媒体服务器的重复数据删除数据库中的数据块传输和记录到S3。 简而言之-以前没有任何备份中的VM。
还原时，媒体服务器会从S3请求必要的重复数据删除对象，对其进行重新水化处理并将其传递给CPC代理，即 必须在还原过程中考虑流量，这将等于要还原的实际数据量。
看起来是这样的：
这是另一段日志169作业（0排队0活动0等待重试0暂停0未完成169完成-选择1）
作业ID类型状态状态详细信息状态作业策略作业计划客户端媒体服务器启动时间逝去时间结束时间存储单元尝试操作千字节文件路径名％完成（估计）作业PID所有者复制父作业ID KB /秒活动开始活动活动机器人库配置文件会话退出数据移动的ID介质主机外类型主优先级重复数据删除率传输加速器优化实例或数据库共享主机
-1372恢复完成0 nbpr01 NBCC 2018年12月19日1:05:58 PM 00:04:32 2018年12月19日1:10:30 PM 1 14,380,577 1 100％8548根1372 70,567 2018年12月19日1:06:00 PM 00:04:30胜利-*********** 90,000
数据的完整性通过S3本身的保护来确保-那里有很好的冗余以防止硬件故障（例如硬盘主轴损坏）。
媒体服务器需要4 TB的缓存-这是Veritas建议的最小大小。 更好，但是我们做到了。
总结
当合作伙伴向我们的S3中投入20 GB时，我们存储了60 GB，这是因为我们提供了3次数据地理保存。 现在流量减少了很多，这对通道和存储收费都有利。
在这种情况下，路线是通过“大型Internet”封闭的，但是您可以通过Internet通过VPN L2来吸引流量，但是最好将媒体服务器设置为提供商的入口。
如果您有兴趣在我们的俄罗斯数据中心中学习这些功能，或者对实施有疑问，请在评论中提出或发送电子邮件至ekorotkikh@croc.ru。