2013年Dell_容灾解决方案.pptVIP

数据保护规划最佳技术实践 演讲者: 白云 企业被淹没在数据之中，并遭受数据保护和管理问题 遭遇重大业务数据丢失事故的企业，43%从未重新开业，51%在两年内关张，只有 6%能长期生存 1 20%的备份和 32%的复原失败 2 57%的受访者使用备份应用程序来存储记录 /数据以进行长期数据留存3 平均70%的数据被复制并且/或者超过90天未被访问 4 未来五年数据将增长650% 。 80% 为非结构性数据! 5 3 只注重备份工作 工作完成即认为已经成功 未提前设计解决方案 直接跳到实施环节 尚未明确界定需求 滥用 “最佳实践” 增加数据卷 给解决方案加上额外的压力 难于给新数据分类 导致 期望与能力不相符 在某些领域过度支出，剥夺了其它领域的开支 将预算浪费在不解决问题的产品之上 解决方案不能恰当地支持业务 4 为何备份问题如此普遍？ 5 DELL建议 6 解决问题 改变反应式的行为 较少地盯着错误与故障、速度与反馈 最重要的问题听起来不像警告 备份工作可能已成功完成，但仍然无法恢复 这些问题等发现时已经太晚 定义怎样才算“好” 更快就是更好吗？ 需要什么投资？ 一个好的解决方案有赖于“已明确界定的需求” 在恢复的背景下界定 定期恢复测试 发现无法恢复的数据，防患于未然 定义 7 成功：具备这样的能力——根据能支持业务目标的、定义明确的需求复原数据。 RTO(恢复时间目标):经历一次灾难或中断后，一个业务流程必须在其内复原、以避免不可接受后果的时间期限。 RPO(恢复点目标): 由于中断或事故而丢失数据的最长的可忍受期限。 数据保护设计概述 定义各服务层级 记录成功标准 辨别应用程序/业务流程与数据之间的关系 分配各服务层级 辨别限制 设计解决方案 8 服务层级 关键任务型 (MC) 关键任务型服务要求持续不断的可用性。服务中断是不可忍受的，并会立即产生严重损害。几乎不惜任何代价也要实现可用性。 关键业务型(BC) 关键任务型服务要求持续的可用性，虽然短暂的服务中断不会带来灾难性后果。 需要高可用性来实现有效的业务运营。 业务运营型 (BO) 对高效的业务运营有贡献，但不在直接面向客户的服务线上。 行政服务 (AS) 办公生产力工具级别的服务，是业务运营所需的。不希望遇到故障，但即使发生故障也不影响客户，因此较为可忍受。不值得为过高的可用性付出高费用。 9 服务层级 RTO/RPO时间 RTO RPO 留存期限 关键任务型 0-24 小时 5 分钟 15 分钟 25 小时 1-30 天 1 小时 24 小时 30 天 30-365 天 4 小时 1 月 1 年 365 天以上 4 小时 1 年 无限期 关键业务型 0 – 24 小时 15 分钟 30 分钟 25 小时 1 – 35 天 1 小时 24 小时 30 天 30-365 天 4 小时 1 月 1 年 365 天以上 4 小时 1 年 无限期 业务运营型 0 – 30 天 4 小时 24 小时 30 天 行政服务 0 – 30 天 4 小时 24 小时 30 天 服务层级 10 数据集 / 应用 服务层级 备注 Exchange 关键业务型 文件与打印 业务运营型 SAP 关键任务型 交易跟踪系统 业务运营型 实地派遣 关键任务型 层级分配 11 限制 网络带宽 首要存储容量可轻松扩展 备份存储容量可轻松扩展 两者之间的通道成为瓶颈 系统或存储性能 数据从磁盘寻回的速度 应用性能/可用性 以备份模式运行可能会牺牲性能 各个备份之间竞争资源 WAN连接 可能使得“保护远程地点的数据”成为挑战 备份窗口 当数据量增多时，备份窗口缩小 白天进行的工作流 工作集 基于应用程序、基于DBMS、基于操作系统 存储软件工具 12 所需的吞吐量 快照技术 复制 快照备份 支持复制功能的磁带或磁盘 支持复制/重复数据删除功能的磁盘备份 磁盘备份 首要存储复制 RTO/数据规模 严格的RTO 严格的RTO/RPO 性能敏感型、24/7可用的应用程序 异地拷贝 远程办事处 通过缓慢的网络链路备份 备份到远程站点时的低RTO/RPO 要求/限制 特性 / 组件 13 解决方案组件 本地数据保护 1、恢复保存在块存储上但是被意外删除的文件 2、恢复保存在文件存储上但是被意外删除的文件 3、将损坏的卷还原到之前的版本 4、还原 SQL 或 Exchange 数据库的损坏部分 5、使用快照或 NDMP 恢复到文件系统卷的之前版本 6、通过使用快照提高备份软件的性能 数据保护使用情形 远程数据保护 7、将数据整合到集中位置以便备份 8、保护块数据免受灾难影响 9、针对计划停机提供高可用性 10、针对意外停机提供高可用性 数据保护使用情形（续） 使用情形 2：恢复保存在文件存储上但是被意外删