2013年数据库技术大会门票、京东100元礼品卡、社区新春福章，仅下载资料一份即可获得

wy071218

支持并下载，谢谢！

dragonphenix

支持，已经下载了。
我回的帖子怎么需要审核？

dragonphenix

1. 如何做到备份即服务，以达到恢复时间目标和恢复点目标需求？

• 在数据中心范围内扩展虚拟化：借助新的备份和恢复方法帮助公司加速和虚拟化更多工作负载，同时提供高效备份和全面恢复。
• 创建集中的备份存储库并高效地扩展：借助重复数据消除、变更数据块跟踪等方案，实现数据丢失时最小化业务中断以及提高总体工作效率。
• 集成备份和恢复产品与方法：借助软件与存储紧密集成的备份和恢复解决方案，提高性能并简化日常管理和支持。
• 为 IT 即服务提供基础：在自助服务门户中，构建备份和恢复流程平台和服务目录，支持业务需求(如SLA)，打破效率瓶颈。

dragonphenix

1. 如何做到备份即服务，以达到恢复时间目标和恢复点目标需求？

在数据中心范围内扩展虚拟化：借助新的备份和恢复方法帮助公司加速和虚拟化更多工作负载，同时提供高效备份和全面恢复。
创建集中的备份存储库并高效地扩展：借助重复数据消除、变更数据块跟踪等方案，实现数据丢失时最小化业务中断以及提高总体工作效率。
集成备份和恢复产品与方法：借助软件与存储紧密集成的备份和恢复解决方案，提高性能并简化日常管理和支持。
为 IT 即服务提供基础：在自助服务门户中，构建备份和恢复流程平台和服务目录，支持业务需求(如SLA)，打破效率瓶颈。

dragonphenix

知道了，发帖内容需要审核，原来是内容里有unicode字符的原因。

Ryan-liumin

支持，已经下载了

dy2216

已下载。必须要支持。

leonarding

如何做到备份即服务，以达到恢复时间目标和恢复点目标需求？
一个适合客户使用的容灾备份系统要保证灾难发生时系统能够做到最快恢复和最小损失。RPO和RTO是衡量容灾系统的两个重要指标。RPO(Recovery Point Objective) 是指灾难发生后，容灾系统能把数据恢复到灾难发生前时间点的数据，它是衡量企业在灾难发生后会丢失多少生产数据的指标。RTO(Recovery Time Objective)则是指灾难发生后，从系统宕机导致业务停顿之刻开始，到系统恢复至可以支持业务部门运作，业务恢复运营之时，此两点之间的时间。RPO可简单的描述为企业能容忍的最大数据丢失量，RTO可简单的描述为企业能容忍的恢复时间。理想状态下，希望RTO=0，RPO=0，即灾难发生对企业生产毫无影响，既不会导致生产停顿，也不会导致生产数据丢失。但显然这不现实，是乌托邦式的梦想。企业要做的是尽量减少灾难造成的损失。RTO 时间越短，即意味要求在更短的时间内恢复至可使用状态。

如何既要提升业务跨平台灵活性，又能保护数据安全性？
现在有很多跨平台的日志复制软件，几大数据库厂商和存储厂商都有自己的产品。
我认为业务数据迁移，分为小批量 多层次 和大批量 少层次的分别
如果迁移的项目很复杂，层次过多，那么我们可以小批量一点一点的移过去，如果发现问题影响面较小
如果迁移的项目比较简单，层次过少，那么我们可以大批量去移动过去，比较方便

wang125

注册，支持，并下载！

边-城

已下载。

喊了一大堆服务啊，灵活啊，高效啊，都是浮云。其实本质就一个备份，一个备份系统搭建首先要确定一个备份架构，备份系统采用什么架构看你有什么样的备份需求。比如，如果数据量大、服务器多，这样的话最好能够使用LAN-FREE架构，如果数据量小，那就直接LAN备份得了，只是举个例子。其次就是备份策略，如果一个企业有RPO和RTO这样的要求，那么备份策略的创建要参考RPO和RTO，并且结合自己的实际环境。没有最好的备份策略，但是总是有最适合自己的备份策略，一个好的备份策略首先是可行或者可恢复的，其次备份策略的产生要结合自己的备份环境，比如，要结合你的磁带库容量，备份带宽，主机性能，备份窗口等等。 最后就是恢复演练了，一个备份是否可靠，只有演练了才知道，所以要定期进行恢复演练。
  综上，个人对备份的观点就是：确定好备份架构、制定好备份策略、定期恢复演练。