金蝶K3 WISE v12.1数据备份与恢复方案

第一篇：金蝶K3 WISE v12.1数据备份与恢复方案

金蝶K3 WISE v12.1数据备份与恢复方案

1、备份策略

用户系统上线后，必须为用户建立本地的系统备份。备份策略符合以下要求：  自动备份：建立数据库定时作业，自动实现按日的数据全备份。服务器上的备份数据保存一周。

 异地保存：每日的备份数据除了在服务器上保存之外，需通过自动程序或手工方式在用户方系统管理员本机上进行异地保存。

 指定专人：用户方必须用专人负责数据备份的日常管理工作。

2、数据备份步骤

该系统备份有两种方案：利用SQL Server或金蝶K3 WISE v12.1自带的备份策略。（1）本系统的备份利用SQL-Server提供的数据库维护计划，如下图所示：  新建数据库维护计划，选择需要备份的数据库。

 一直“下一步”直到下图所示：

第1页

共6页

 点击上图中的更改按钮进行作业调度设置需要的备份计划。

 选择“下一步”如下图所示进行备份目录和备份数据保留天数的设置。

第2页

共6页

 一直点“下一步”直到完成。

（2）本系统的备份利用金蝶K3 WISE v12.1提供的账套管理中的备份策略。 在服务器上单击桌面工具栏的“开始”—“程序”—“金蝶K3 WISE 创新管理平台”—“金蝶K3服务器配置工具”—“账套管理”，登录后，如下图所示：

 单击“账套自动批量备份”，在弹出的窗口中录入相关信息，如下图示：

第3页

共6页

 按提示操作，直到完成。

3、恢复策略

当用户系统故障需要恢复时，先尝试利用服务器端保存的数据进行恢复，若服务器端数据不可用，再使用异地的备份数据。

4、数据恢复步骤

该系统恢复也有两种方案：利用SQL Server或金蝶K3 WISE v12.1自带的恢复策略。（1）本系统的恢复可以利用SQL-Server提供的还原数据库进行系统恢复。步骤如下：  选择需要还原的数据库，单击鼠标右键，选择所有任务—〉还原数据库，如下图所示：

第4页

共6页

 在下图中选择“从设备”，然后点击“选择设备”。

 “添加”需要恢复的备份集，确定以后即可进行数据的恢复。（2）本系统的恢复利用金蝶K3 WISE v12.1提供的账套管理中的恢复策略。

 在服务器上单击桌面工具栏的“开始”—“程序”—“金蝶K3 WISE 创新管理平

第5页

共6页

台”—“金蝶K3服务器配置工具”—“账套管理”，登录后，如下图所示：

 单击“恢复账套”，在弹出的窗口录入相关信息，如下图示：

 按提示操作，直到完成。

第6页

共6页

第二篇：ORACLE数据备份与数据恢复方案

ORACLE数据备份与数据恢复方案

摘 要

结合金华电信IT系统目前正在实施的备份与恢复策略，重点介绍电信业务计算机管理系统(简称97系统)和营销支撑系统的ORALCE数据库备份和恢复方案。

Oracle数据库有三种标准的备份方法，它们分别是导出／导入（EXP/IMP）、热备份和冷备份。要实现简单导出数据（Export）和导入数据（Import），增量导出／导入的按设定日期自动备份，可考虑，将该部分功能开发成可执行程序，然后结合操作系统整合的任务计划，实现特定时间符合备份规划的备份应用程序的运行，实现数据库的本级备份，结合ftp简单开发，实现多服务器的数据更新同步，实现数据备份的异地自动备份。

关键字：数据库 远程异地 集中备份

I

ORACLE数据备份与数据恢复方案

目 录

一、前 言 ··························· 1

二、金华电信ORACLE数据库的备份与恢复方案 ······· 2

2.1 备份系统数据库备份策略································································································· 3 2.2 备份系统数据库恢复策略···················· 3 2.3 金华电信97系统及营销支撑系统的系统状况 ··········· 3 2.4 金华电信97系统、营销支撑系统及备份系统总体结构图 ······ 4 2.5 备份系统结构图说明······················ 4

三、金华电信97系统的数据库备份和恢复 ········ 6

3.1 备份方法··························· 6 3.2 备份策略··························· 6 3.3 恢复策略··························· 6 3.4 性能影响··························· 6

四、金华电信营销支撑系统的备份与恢复········· 7

4.1 备份方法··························· 7 4.2 备份策略··························· 7 4.4 性能影响··························· 7

五、RMAN CATALOG 数据库的备份 ············ 8

II

ORACLE数据备份与数据恢复方案

六、结 语 ······················ 9

III

ORACLE数据备份与数据恢复方案

一、前 言

目前，数据已成为信息系统的基础核心和重要资源，同时也是各单位的宝贵财富，数据的丢失将导致直接经济损失和用户数据的丢失，严重影响对社会提供正常的服务。另一方面，随着信息技术的迅猛发展和广泛应用，业务数据还将会随业务的开展而快速增加。但由于系统故障，数据库有时可能遭到破坏，这时如何尽快恢复数据就成为当务之急。如做了备份，恢复数据就显得很容易。由此可见，做好数据库的备份至关重要。因此，建立一个满足当前和将来的数据备份需求的备份系统是必不可少的。传统的数据备份方式主要采用主机内置或外置的磁带机对数据进行冷备份，这种方式在数据量不大、操作系统种类单

一、服务器数量有限的情况下，不失为一种既经济又简明的备份手段。但随着计算机规模的扩大，数据量几何级的增长以及分布式网络环境的兴起，将越来越多的业务分布在不同的机器、不同的操作平台上，这种单机的人工冷备份方式越来越不适应当今分布式网络环境。

因此迫切需要建立一个集中的、自动在线的企业级备份系统。备份的内容应当包括基于业务的业务数据，又包括IT系统中重要的日志文件、参数文件、配置文件、控制文件等。本文以ORACLE数据库为例，结合金华电信的几个相关业务系统目前正在实施的备份方案，介绍ORACLE数据库的备份与恢复。

ORACLE数据备份与数据恢复方案

二、金华电信ORACLE数据库的备份与恢复方案

由于金华电信IT系统以前只采用逻辑备份方式进行数据库备份，速度较慢并且数据存储管理都很分散，甚至出现备份数据不完整的现象。为了提高备份数据的效率，提供可靠的数据备份，完善备份系统，保证备份数据的完整性，降低数据备份对网络和服务器的影响，对每个IT系统的备份数据进行集中管理，我们对备份工作进行了改进，将逻辑备份与物理备份相结合，在远程建立了一个异地集中、自动在线的备份系统即网络存储管理系统。（这里用到的物理备份指热备份）其具备的主要功能如下：(1)集中式管理 :网络存储备份管理系统对整个网络的数据进行管理。利用集中式管理工具的帮助，系统管理员可对全网的备份策略进行统一管理，备份服务器可以监控所有机器的备份作业，也可以修改备份策略，并可即时浏览所有目录。所有数据可以备份到同备份服务器或应用服务器相连的任意一台磁带库内。(2)全自动的备份: 对于大多数机房管理人员来说,备份是一项繁重的任务。每天都要小心翼翼,不敢有半点闪失,生怕一失足成千古恨。网络备份能够实现定时自动备份，大大减轻管理员的压力。备份系统能根据用户的实际需求，定义需要备份的数据，然后以图形界面方式根据需要设置备份时间表，备份系统将自动启动备份作业，无需人工干预。这个自动备份作业是可自定的,包括一次备份作业、每周的某几日、每月的第几天等项目。设定好计划后，备份作业就会按计划自动进行。(3)数据库备份和恢复: 数据库系统已经相当复杂和庞大，不能用文件的备份方式来备份数据库。企业级的备份系统能够对数据库在不中断业务、不停顿数据库的情况下对数据进行联机的自动备份，包括可以进行数据库备份、日志备份、完全备份、增量备份等。(4)归档管理: 用户可以按项目、时间定期对所有数据进行有效的归档处理。提供统一的数据存储格式从而保证所有的应用数据由一个统一的数据格式来作永久的保存，保证数据的永久可利用性。(5)有效的媒体管理: 备份系统对每一个用于作备份的磁带自动加入一个电子标签，同时在软件中提供了识别标签的功能，如果磁带外面的标签脱落，只需执行这一功能，就会迅速知道该磁带的内容。(6)满足系统不断增加的需求:备份软件必须能支持多平台系统，当网络连接其它的应用服务器时，对于网络存储管理系统来说，只需在其上安装支持这种服务器的客户端软件即可将数据备份到磁带库或光盘库中。

ORACLE数据备份与数据恢复方案

2.1 备份系统数据库备份策略

数据库运行在归档模式下，利用Veritas软件模块调用数据库的备份接口进行在线的热备份，可以在备份时，对备份数据保存在不同的存储对象中，以满足客户容灾的要求，可以利用Veritas的多线程的数据迁移、利用多个磁带驱动器同时读写提高其数据备份的效率。

针对数据库的总数据量和增量数据量大小，我们可以利用数据库的多级的增量备份机制，结合Veritas 强大的备份数据追踪寻址能力和介质管理功能，制定灵活的备份策略，实现全自动的备份数据的全生命周期管理。

2.2 备份系统数据库恢复策略

通过本地的Veritas Server结合Veritas for Databases利用备份数据进行数据恢复。恢复时，Veritas 可以实现多线程的数据恢复，利用Veritas 独特的磁带分类集中存放技术，减少磁带的就位时间，提高数据恢复的效率。

先用最近一次的全备份恢复＋恢复最近一次的增量备份＋增量备份到断点的ARCHIVE LOG来恢复（要求数据库在ARCHIVE LOG模式下工作）。这种恢复方式比全部用ARCHIVE LOG恢复要快。

如果两份冗余的最近一次增量备份都不可用，可以追溯再上次的增量备份来恢复，然后用增量备份到断点的ARCHIVE LOG恢复。

如果最近一次的全备份恢复都不可用,则利用上个周期的全备份＋上个周期的最后一次增量备份＋本周期的最近一次增量备份＋增量备份到断点的ARCHIVE LOG来恢复。

如果增量备份都不可用，那么用全备份＋ARCHIVE LOG来恢复。

2.3 金华电信97系统及营销支撑系统的系统状况

金华电信经过这么多年的信息系统建设，目前已经运行着多个系统，除计费系统有较为完善的备份系统外，其他系统的备份系统都需要完善。其中97系统的机器型号IBM 7040-61R，操作系统 AIX5.2，数据库类型ORALCE8.1.7.4，数据量120G；营销支撑系统机器型号IBM xseries440，操作系统Red Flag Linux Server 4.0,数据库类型ORACLE9.2.0.1,数据量150G。以前,这两个系统的数据备份都是通过逻辑备份(exp)实现并且备份数据管理是分散的，然而一个完善的备份系统必须包含物理备份和逻辑备份两种方式。因此，我们正在实施一个远程

ORACLE数据备份与数据恢复方案

异地在线集中的高效的备份系统，将逻辑备份和物理备份（热备份）相结合，设置了专门的备份服务器。由于97、营销支撑操作系统采用AIX及Red Flag，我们在备份服务器上安装了第三方备份软件Veritias NBU。

2.4 金华电信97系统、营销支撑系统及备份系统总体结构图

对于具体的备份环境和结构,我们结合了Oracle备份技术和LAN环境的SAN备份结构.该系统的结构如下图所示（以97系统与营销支撑系统为例）

备份系统总体结构图

2.5 备份系统结构图说明

此在线存储系统采用了基于SAN（存储区域网络）的结构，SAN是一种高速

ORACLE数据备份与数据恢复方案

网络或子网络，提供在计算机与存储系统之间的数据传输。存储设备是指一张或多张用以存储计算机数据的磁盘设备。一个 SAN 网络由负责网络连接的通信结构如光交换机、负责组织连接的管理层、存储部件以及计算机系统构成，从而保证数据传输的安全性和力度。由于整个SAN系统的数据量比较大，所以备份系统采用SAN结构，将磁盘阵列直接连接到SAN的交换机上，和备份服务器、多台服务器均通过SAN相互连接，利用SAN的高性能来提高备份速度、降低数据备份对网络和服务器的影响。备份系统结构图说明如下:(1)Veritas 服务器(即备份服务器):备份系统是数据安全的关键系统，而备份服务器是备份系统的核心，因此从安全可靠的角度，采用专用的备份服务器，在这台服务器上安装VERTIAS Server端软件，集中管理控制磁带库、定制备份策略、管理备份作业、管理磁带等，同时安装oracle catalog库。(2)备份方案:对97系统购买IBM VERTIAS 备份软件，将数据备份至磁盘阵列上面，备份数据走光纤通道。对营销支撑系统，我们从SAN存储的FATA盘上划部分空间直接挂到系统中，然后直接采用RMAN做备份，以降低成本。之所以采用FATA盘的目的是为了避免和FC盘有IO冲突。(3)M300磁盘阵列:在我们的方案当中，我们采用磁盘阵列来代替一贯采用的磁带库。磁盘阵列具有性能高，可靠性高，维护方便等优点。本方案中采用专业存储厂商富士通的中高端存储ETERNUS3000 M300，作为一种面向开放系统的存储系统，ETERNUS3000在性能、容量及连通性等方面将世界标准提高到一个新层次。M300的容量为6T的FC盘，10T的FATA盘。在FC盘上保留所有系统的一份全备，其他的备份在白天定期转移到FATA盘。在FATA盘上保留1-2份全备，其他的定期转移到3583磁带库中。(3)光纤交换机:为了使整个系统具有良好的扩展性，我们在数据中心采用了被评为最优秀的网络存储产品博科的16口的光纤交换机，在新大楼备份中心采用博科的8口的光纤交换机。(4)磁带库:本方案中的磁带库采用的是原先计费系统所用的3583磁带库。我们定期将FATA盘上的备份自动转移到该磁带库上，做更久的保留。(5)逻辑备份服务器:为了充份利用旧有的设备来提高异地集中备份系统的稳定性，安全性，我们利用旧有设备IBM 7044-170小型机和IBM 3542阵列来搭建一个逻辑备份系统。所有的逻辑备份都放到该机器上面来，使得逻辑备份和物理备份在物理上开离。这样一来避免了IO冲突，二来提高了备份系统的可靠性。

ORACLE数据备份与数据恢复方案

三、金华电信97系统的数据库备份和恢复

3.1 备份方法

采用Veritas NBU物理备份加EXP逻辑备份。Exp逻辑备份在服务器上直接备份，定期转移到逻辑备份服务器。

3.2 备份策略

备份策略:(1)每周进行一次数据库全备份操作，并定期将FC盘上面的物理备份定期转移到FATA盘上，同时将FATA盘阵上面的物理备份定期转移到磁带库上，至少保存 3 个全备份；全备份时间选择在每周星期六凌晨12：00 开始。(2)数据库采用Archive Log 模式，每天晚上12：00 开始进行增量备份。(3)与数据库的逻辑备份相配合，我们每天进行一次数据的exp备份，即每天做一个完整的数据库EXPORT 备份；备份时间选择在每天凌晨1：00 开始。Exp备份还是备到本机，定期将其ftp到逻辑备份服务器上。

3.3 恢复策略

恢复策略:(1)数据文件损坏或磁盘阵列损坏：针对这种情况可以采用Veritas NBU从FC磁盘阵列中恢复。(2)误操作或对象级逻辑上的损坏：针对这种情况可以从exp备份中采用imp恢复。

3.4 性能影响

数据库采用归档模式对97数据库性能将产生一定的影响。因为在归档模式下，oracle需要将归档日志归档到归档目录(也就是copy)。在IO资源不成为瓶颈的情况下，对系统影响将可以不予考虑。97系统目前的瓶颈在于内存这一块。所以对97系统的性能影响可以不加以考虑。

ORACLE数据备份与数据恢复方案

四、金华电信营销支撑系统的备份与恢复

4.1 备份方法

采用物理备份加EXP逻辑备份。物理备份考虑到VERTIAS 的成本，及该系统的重要程度，我们从SAN存储上划一部分空间挂接至该系统OS上面，然后直接采用RMAN备份。这样备份的好处是成本低，缺点是不便于管理和维护，消耗主机的资源，在主机无法启动的情况下，备份文件无法访问，但备份数据还是完好如初的。

4.2 备份策略

备份策略:(1)每周进行一次数据库全备份操作，采用循环覆盖的方式，共保存 2个全备份；备份时间可以选择在周日晚上11：00进行(由于其采用的是FATA盘，与其他的物理备份不会造成IO冲突)。(2)数据库采用Archive Log 模式，每天晚上12：00 增量备份。(3)与数据库的逻辑备份相配合，我们每周进行一次数据的exp备份，即每天做一个完整的数据库EXPORT 备份；备份时间选择在每天凌晨1:00 开始。

4.3 恢复策略

恢复策略:(1)数据文件损坏或磁盘阵列损坏：针对这种情况可以采用RMAN从磁盘中恢复。(2)误操作或对象级逻辑上的损坏：针对这种情况可以从exp备份中采用imp恢复。

4.4 性能影响

数据库采用归档模式对营销支撑系统数据库性能产生的影响也是由于归档进程需要对归档日志进行归档。同时改成归档模式还需要注意的一个问题就是归档目录空间的问题，该系统空间足够。如果该系统的IO资源较为充裕的话，则不会对性能产生很大的影响。

ORACLE数据备份与数据恢复方案

五、RMAN Catalog 数据库的备份

RMAN Catalog库是整个备份系统当中最重要的信息之一。是在物理备份（Veritas）服务器上建立的一个ORACLE数据库，记录了所有备份的数据库数据文件。如果丢失了Catalog信息的话，恢复将非常麻烦，因此我们也需要对RMAN Catalog库做定期备份。RMAN Catalog库采用逻辑备份，每天直接备份到逻辑备份服务器上。

ORACLE数据备份与数据恢复方案

六、结 语

数据库的备份和恢复的主要工作就是为数据做了一份拷贝，防止出现故障时导致数据的丢失。数据库受破坏一般是由于两种情况引起，其一为系统（软件）故障，如掉电、SQL Server错误、操作系统错误、非正常关机等引起。其二为磁盘（介质）故障，由磁盘受破坏引起。若出现介质故障（如磁盘崩溃），当且仅当对数据库及事务日志做了定期备份，才能恢复数据库。在实际应用中，应根据具体的情况，采纳一切可以用的方法，制定切合实际的备份和恢复方案，明确在各种故障情况中数据可恢复的程度是否满足了应用的需要。为了保证数据存储的可管理性，减少管理的复杂性，建立一个异地集中、在线的备份系统是必不可少的。采用先进的备份技术和先进的备份系统软件，采用统一的管理机制，保证大数据量的一致性备份和高速切换。从而提供高效的存储设备的管理能力和可靠的数据备份功能。

第三篇：数据备份和恢复管理规范

数据备份和恢复管理规范

第一章 总 则

第一条 为规范、统一全集团范围内重要系统的数据备份及管理工作，明确各系统数据备份及恢复的角色和职责，确保备份介质的安全和按时、顺利恢复系统和数据，并确保有关责任人员熟练掌握系统和数据的备份、归档和恢复流程，特制定本办法。

第二条 备份和恢复管理的范围包括：确定关键系统的备份和恢复方针及原则；系统、应用等软件及业务、配置等数据的备份和恢复；备份介质的存放、归档管理；系统及数据恢复演练；备份和恢复流程的评估和维护；归档数据的查询；备份和恢复所需存储、磁带库等硬件工具/设备的监控和管理。不包括：硬件、网络的备份和恢复（属于业务连续性管理）；业务系统的在线数据冗余（属于业务可用性管理）。

第三条 关键系统定义： ERP、研发、SCM、CRM、财务、HR和其他多个单位通用的业务系统；MIP、邮件、公共网站等IT基础应用系统；单个单位使用的核心业务系统。

第四条 集团数据备份和恢复工作由集团备份管理员负责组织、协调，并按照既定计划和策略督促相关人员执行。

第二章 数据备份、归档和恢复原则

第五条 备份和恢复时间、性能应符合各系统服务级别的规定，各系统服务级别由系统所在单位与系统主要使用部门商议。

第六条 应考虑主机系统（操作系统、工具软件、数据库系统软件、应用等）变化的频率，全备份的频率应与业务系统变化频率成正比。

第七条 当主机系统发生较大更改时，应马上对主机系统进行一次全备份。第八条 应考虑全备份的容量，全备份的频率应与其备份容量成反比。第九条 系统全备份方式适用于使用小型机设备的系统，使用PC服务器的系统建议采用克隆系统应急盘方式。

第十条 对应用软件等程序文件：当系统配置数据发生变动时，应马上备份，备份介质保留至下一次系统全备份。当生产环境中的应用软件将发生变动时，应对变动前的应用软件进行备份。该种情况下的备份一般情况下由各系统管理员自行准备资源完成。

第十一条 对Oracle等数据库进行在线备份的系统，原则上要求周日为0级备份（冷备份）。对有数据长期保留需求的系统，只进行系统的0级备份的归档，以确保数据有效性和可恢复性。

第十二条 归档数据一般包括程序文件、数据文件，一般不包括数据库归档日志、逻辑备份数据（如在线备份）。

第十三条 归档数据完整性的基本原则：进行数据恢复后，系统在简单配置后可直接使用。

第十四条 对业务数据备份：在网络带宽和存储设备允许的前提下，可以采用集中备份和恢复管理的方式，否则采用分布备份和恢复管理方式。在数据库故障时能够快速恢复数据是选择备份方式的一个重要因素。应该采用多种备份方式（如采用块方式和文本方式等），以保证除了使用备份系统进行恢复外，还可以在本地备份机上直接恢复应用，如特别关键应用，建议考虑增加异地的恢复方式。除了用于恢复外，备份介质还应该方便存档数据查询、恢复演练、新系统测试、审计检查等使用。重点保留月末、季末、年末、结息日、新系统切换等重点时间的数据。

第十五条 对Oracle数据库备份：为了保护最近产生的数据，必须连续备份数据库逻辑日志。在业务数据的两次连续0级备份之间，应该进行业务数据逻辑日志的备份。

第十六条 应该根据数据容量/备份持续时间来决定采用每日0级备份，或定期0级备份+每日增量备份方式（增量备份分为对上次0级备份的增量、对上次增量的增量两种）。如果每日0级备份的备份和恢复时间符合要求，建议采用每日0级备份方式；否则采用每周0级备份+每日增量备份方式。备份介质保留一个备份周期。

第十七条 区别维持关键业务运行的数据（如，仅仅包含账户数据、客户信息、交易数据，不含历史数据），并每日单独备份，剩余数据同样单独备份。考虑到是快速恢复数据，故该类数据不宜过大。另外考虑到其使用目标是仅仅是应急，故其备份介质都是短期保留。

第十八条 要使用脚本来进行备份和恢复，尽量避免手工操作；尽量安排在非工作时间备份。

第十九条 在备份和恢复操作流程发生变动时，应该对操作人员进行培训；进行恢复演练的频率与流程变化的频率成正比；进行实际恢复演练的频率与恢复失败的频率（考核指标之一）成正比。

第二十条 所有对生产系统和数据的恢复都要预先得到批准；对存档备份介质的调阅需要登记，并且只能拷贝不能外借。

第二十一条 所有的备份介质都要贴上清晰的标签，标签应包含介质编号（或序号）、备份内容、备份日期时间、备份人员等内容；数据备份在制作、传递、转移过程中，必须填写《数据备份登记表》或《数据转移保存登记表》，详细记录备份数据制作、传递、转移的全部过程与责任人；数据备份的存放处必须符合防火、防水、防磁的安全要求；保存期在一年以上的备份磁带应半年进行重写或重绕处理；长期保存的磁带应记录使用次数，保证介质在规定的次数内使用；归档数据备份介质应该实施异地存放，建议存放至银行保险箱或档案室（必须和主机房不在同一建筑物内，如分支机构办公场所）。

第三章 存储、备份设备及相关设备管理

第二十二条 存储设备：集团中央数据存储系统、集团中央备份存储系统；备份管理员负责：每天检查存储设备控制器产生的信息，每周至少一次现场检查存储设备及相关部件运行状况，并将检查记录包含在周报中；存储设备Lun的调整和新Lun的分配，磁盘Raid策略调整等资源使用管理；

第二十三条 备份设备：STK SL500磁带库、LTO3数据磁带、LTO3清洗带；磁带库设备要求制定驱动器自动清洗策略，备份管理员负责：定期检查策略执行执行是否正常，每周至少一次现场检查磁带库及相关部件运行状况，并将检查记录包含在周报中；根据备份策略或用户需求调整，及时调整磁带库设备的资源分配。

第二十四条 相关设备：光纤通道交换机及光纤通道接口等部件、主机HBA卡；备份管理员负责：每周至少一次现场检查光纤通道交换机及相关部件运行情况，并将检查记录包含在周报中；每月协助系统管理员对主机HBA卡运行情况进行检查，包括双通道、负载均衡功能是否正常以及操作系统是否出现类似光纤通道报警信息；交换机Zooning调整、划分及相关资源调配。

第二十五条 备份管理员负责以上设备的日常维护和故障报修。维护和报修流程见本规范第二十九条第2款。

第四章 备份和恢复相关人员职责

第二十六条 集团备份管理员由集团IT管理部任命和管理；二级备份管理员由二级管理平台IT部门任命和管理，在备份业务上配合集团备份管理员。增加二级备份管理员的调整须提前知会集团IT管理部。系统管理责任人由系统所在平台的IT部门确定，业务管理责任人由系统所在平台的关键业务部门确定。

第二十七条 集团备份管理员职责：作为集团数据备份和恢复工作的总体计划制

定和工作协调者，负责备份系统管理和日常维护；负责备份数据在磁带、光盘等可移动存储介质上克隆、迁移和本地存放；参与备份系统建设、改造项目；协助二级备份管理员和各系统管理员进行数据覆盖和灾难恢复工作；定期组织二级备份管理员及相关人员进行备份数据有效性验证；负责组织集团本部相关系统管理员进行备份数据的有效性验证工作；负责备份系统客户端程序的异常处理，但不含客户端程序的管理；有义务和责任对系统管理员制定的备份策略提出合理建议；根据各系统恢复演练要求，制定总体恢复演练工作计划。

第二十八条 二级备份管理员职责：作为二级平台及下属单位数据备份和恢复工作详细计划的制定和协调者，协助备份管理员维护工作；组织相关系统管理员进行备份系统客户端的日常维护；协助备份管理员定期组织相关人员进行备份数据的有效性验证；参与备份系统建设、改造项目；负责平台管理范围内系统进行数据覆盖和协助集团备份管理员完成灾难恢复工作；负责制定该平台及下属单位的系统恢复演练详细计划，并负责该平台及下属单位数据从备份系统的导出。

第二十九条 系统技术管理责任人职责：简称系统管理员。是系统管理责任部门指定的系统日常维护人员，作为数据备份策略的制定者和恢复工作的实际执行者，按照《备份系统维护指引》要求，负责对备份系统客户端的维护；根据业务系统数据安全需求，负责制定合理、有效的备份策略(系统管理员只能负责提出策略和有效性审核，策略的合理性应由集团备份管理员完成)；在集团备份管理员或二级备份管理员的协助下，负责进行责任系统的备份数据有效性验证；根据灾难演练计划，建立系统详细恢复操作文档，并负责具体系统的搭建、恢复工作，同时负责组织相关人员对恢复系统的有效性进行测试并提交相关报告。（各个应用系统需要确定主要维护责任部门，由责任部门提出对系统的维护要求和指标）

第三十条 系统业务管理责任人职责：作为数据备份和恢复工作的用户方或负责业务维护的项目组，负责确认系统数据备份和恢复的时间、性能等指标。ERP、SCM、CRM等类系统业务责任部门为系统所在单位财务部门，研发类系统业务责任部门为系统所在单位研发部门，集团HR系统业务责任部门为集团人力资源部，MIP、邮件等基础应用系统业务责任部门为集团IT部。其他系统由系统管理的责任单位IT部门确定系统业务责任部门。

第五章 运维管理流程

第三十一条 数据备份异常的预警机制：对于连续两次备份失败的系统，集团备份管理员应以邮件、短信或电话方式知会二级备份管理员或相关系统管理员及该管理平台IT部门负责人，系统管理员应积极采取相关措施，二级备份管理员及集团备份管理员应配合，确保当天晚上数据备份成功，连续三次备份失败，集团备份管理员应将该信息抄送至系统责任单位财务负责人、集团IT总监。

第三十二条 系统日常维护流程：备份系统的服务器端操作，由备份管理员负责，客户端操作由相关责任人负责，备份管理员协助完成。

1.备份情况通报流程：集团备份管理员每天上午10点前将前一天晚上数据备份情况在MIP上公布（周六备份情况在周一通报），每周备份管理员将一周备份情况进行总结并发布至MIP，内容包括但不限于：本周备份数据量、备份有效性总结、故障处理情况；每月进行一次系统运行情况总结，上报至基础管理中心高级经理，内容包括但不限于：本月备份有效性情况、故障处理汇总及分析、系统运行趋势分析及系统改进合理化建议等。对于备份失败的系统，以邮件、短信或电话方式通知二级备份管理员及其上级领导并给出初步诊断结果和建议操作；二级备份管理员应立即联系相关系统管理员，系统管理员应在当天配合备份管理员查找问题。若数据连续两天没有备份成功，第三天需要系统管理员与备份管理员一起确定系统的备份方式，若为数据库的在线备份失败，应采取冷备份，若因数据库没有正确启停，需系统管理员在策略中约定的时间手工启停数据库，保证当晚数据备份成功。如二级备份管理员及系统管理员对备份失败问题一天内查不出原因，集团备份管理员应协调相关资源协助处理。

2.备份系统日程运维管理流程：包括备份系统及相关设备日常检查及故障处理。备份管理员每天对备份系统软件日志进行查看，如系统出现的报警或故障信息，当天反馈至技术后台支持经理，如超过2天不能解决，应上报至基础运维管理中心高级经理，并联系相关外部技术支持人员。如超过4天不能解决，应上报至集团IT总监。3.备份和恢复策略初次申请流程：由系统管理员提出备份和恢复策略并填写《备份和恢复需求》、《系统备份信息表》、《备份和恢复策略和原则》，系统业务责任人对《备份和恢复需求》进行确认，二级平台备份管理员审查，集团备份管理员审核，并在备份系统中实施，备份管理员直属领导及基础运维管理中心负责人备案。

4.备份和恢复策略变更流程：由系统管理员提出变更后的备份和恢复策略并填写《备份和恢复需求》、《系统备份信息表》、《备份和恢复策略和原则》，系统业务责任人对《备份和恢复需求》进行确认，二级平台备份管理员审查，集团备份管理员审核，并在备份系统中实施，备份管理员直属领导及基础运维管理中心负责人备案。5.备份数据常规恢复流程：常规恢复指数据的测试环境覆盖、恢复演练等要求下进行数据恢复。不允许在凌晨进行数据恢复，如需进行数据，需要以邮件方式发送请求至集团备份管理员，由备份管理员安排恢复时间和协助恢复。如系统管理员自行恢复，导致正常备份工作受到影响，将追究相关管理员责任。

6.系统和数据灾难恢复流程：系统管理员提交系统和数据恢复申请，系统管理员直属领导进行审核，系统业务责任部门审批，根据系统故障类型，二级备份管理员或集团备份管理员准备恢复的介质，系统管理员进行系统和数据恢复，系统业务责任人对恢复数据正确性进行验证，确认恢复成功后，由系统管理部门对外发出《系统恢复通知》。

7.日常备份和归档管理流程：集团备份管理员进行日常备份和归档，提交《备份介质存放登记表》，并在MIP上发布当日备份信息，备份管理员直属领导对归档进行审核和数据抽查，基础运维管理中心负责人备案。

8.备份介质存放管理流程：集团备份管理员对归档的备份介质（目前为磁带）进行异地存放，并填写《数据转移保存登记表》，备份管理员直属领导审查，基础运维管理中心负责人备案。

第三十三条 系统和数据恢复演练流程：包括所有非灾难恢复性质的数据恢复流程。集团或二级平台备份管理员提交《系统和数据恢复演练计划》，同时准备好演练的环境和介质，系统管理员将系统和数据恢复至预定位置，并进行系统和数据恢复结果进行验证，并填写《系统和数据恢复演练反馈表》。

第三十四条 存档数据查询流程：由存档数据查询人提交《存档数据查询申请表》，系统业务责任人审核，系统管理员准备恢复所需硬件、软件等资源，二级备份管理员或集团备份管理员准备恢复环境和备份介质，系统管理员进行数据恢复对恢复系统和数据进行可用性确认，系统业务责任人对恢复系统和数据进行正确性验证，并通知查询人进行数据查询。

第六章 惩罚措施

第三十五条 如集团备份管理员已通知相关系统管理员备份失败信息，而系统管理员没有及时处理，导致两次以上的数据备份失败情况发生，系统管理员应承担数据安全管理不善责任，并在MIP上通报批评，如造成数据丢失等严重后果，按照相关单位规定进行处罚。

第三十六条 因集团备份管理员维护不到位，出现同一套系统数据备份失败情况，且没有及时知会相关系统管理员进行应急处理，导致系统备份失败情况连续发生三天以上（含三天），集团备份管理员将承担系统管理不善责任，并在MIP上通报批评，如由此造成的数据丢失或其他严重后果，按照集团相关规定进行处罚。连续三个月未出现因备份管理员维护不力而出现备份异常情况，由集团IT管理部给予××奖励。

第三十七条 因相关系统管理员未及时处理，而导致连续三天以上备份失败（含三天），系统管理员承担系统维护不善的责任，并在MIP上通报批评，如因此造成的数据丢失或其他严重后果，按系统管理员所在单位相关规定进行处罚。

第三十八条 如无特殊原因，连续三个月内都未组织二级备份管理员及相关系统管理员进行系统灾难恢复演练工作，集团备份管理员应承担系统维护不力责任，并在MIP上通报批评。

第三十九条 二级备份管理员不配合集团备份管理员组织系统灾难恢复演练工作，导致演练工作无法开展，将追究相关责任人责任并在MIP上通报批评。

第四十条 相关系统管理员不服从备份管理员组织，连续三个月内都未进行系统灾难恢复演练工作，将追究相关责任人责任并在MIP上通报批评，因此出现备份数据恢复无效而导致数据丢失情况，由系统管理员及所在部门责任人承担数据安全的全部责任。

第四十一条 本《规范》由集团IT管理部负责修改和解释。第四十二条 此规范自下发之日起执行。

2006年4月9日

第四篇：wps文字备份与数据恢复管理

wps文字备份与数据恢复管理

这篇wps文字备份与数据恢复管理是 小编特地为大家整理的，希望对大家有所帮助!

备份管理

如果WPS Office程序遇到异常情况需要退出的时候，将对正在使用的文件进行分析以查找错误，如果可

能将恢复其中的信息。但在某些情况下，无法恢复任何信息。

在重新启动WPS Office程序，将自动弹出“备份管理”任务窗格，里面列出了程序停止响应时已恢复的

所有文件。

此时，您可以单击“各种备份文件都在这里哦!”打开备份文件目录。通过文件名称、备份时间等信息

找到合适的备份文件进行恢复。

恢复完毕之后，您可以选择手工逐个删除或者全部删除备份文件。

数据恢复

意外删除了文件，磁盘出现损坏等情况了出现时，使用数据恢复功能找回丢失的文件。

操作小贴士

界面左上角“WPS文字”选项中，常规与保存下，可以设置备份的相关选项。启用智能备份时，备份的

默认时间则为10分钟。

第五篇：ORACLE数据备份与数据恢复方案论文.

ORACLE 数据备份与数据恢复方案 学号: 11129149 姓名:文明艺 1 引 言

目前, 数据已成为信息系统的基础核心和重要资源, 同时也是各单位的宝贵财富, 数据 的丢失将导致直接经济损失和用户数据的丢失, 严重影响对社会提供正常的服务。另一方面, 随着信息技术的迅猛发展和广泛应用, 业务数据还将会随业务的开展而快速增加。但由于系 统故障,数据库有时可能遭到破坏,这时如何尽快恢复数据就成为当务之急。如做了备份, 恢复数据就显得很容易。由此可见, 做好数据库的备份至关重要。因此,建立一个满足当前 和将来的数据备份需求的备份系统是必不可少的。传统的数据备份方式主要采用主机内置或 外置的磁带机对数据进行冷备份, 这种方式在数据量不大、操作系统种类单

一、服务器数量 有限的情况下, 不失为一种既经济又简明的备份手段。但随着计算机规模的扩大, 数据量几 何级的增长以及分布式网络环境的兴起, 将越来越多的业务分布在不同的机器、不同的操作平台上,这种单机的人工冷备份方式越来越不适应当今分布式网络环境。

因此迫切需要建立一个集中的、自动在线的企业级备份系统。备份的内容应当包括基于 业务的业务数据,又包括 IT 系统中重要的日志文件、参数文件、配置文件、控制文件等。本文以 ORACLE 数据库为例,结合金华电信的几个相关业务系统目前正在实施的备份方案, 介绍 ORACLE 数据库的备份与恢复。ORACLE数据备份与数据恢复方案 2.1 导出和导入(Export/Import 利用 Export 可将数据从数据库中提取出来,利用 Import 则可将提取出来的数据送回到 Oracle 数据库中去。

1、简单导出数据(Export和导入数据(Import

Oracle 支持三种方式类型的输出:(1表方式(T方式 ,将指定表的数据导出。

(2用户方式(U方式 ,将指定用户的所有对象及数据导出。(3全库方式(Full方式 ,瘵数据库中的所有对象导出。

数据导入(Import的过程是数据导出(Export的逆过程, 分别将数据文件导入数据库和将 数据库数据导出到数据文件。

2、增量导出 /导入

增量导出是一种常用的数据备份方法,它只能对整个数据库来实施,并且必须作为

SYSTEM 来导出。在进行此种导出时,系统不要求回答任何问题。导出文件名缺省为 export.dmp ,如果不希望自己的输出文件定名为 export.dmp ,必须在命令行中指出要用的文 件名。

增量导出包括三种类型:(1“ 完 全 ” 增 量 导 出(Complete即 备 份 三 个 数 据 库 , 比 如 :exp system/manager inctype=complete file=040731.dmp。

(2“ 增 量 型 ” 增 量 导 出 备 份 上 一 次 备 份 后 改 变 的 数 据 , 比 如 :exp system/manager inctype=incremental file=040731.dmp。

(3“ 累积型 ” 增量导出累计型导出方式是导出自上次 “ 完全 ” 导出之后数据库中变化了的 信息。比如:exp system/manager inctype=cumulative file=040731.dmp。

数据库管理员可以排定一个备份日程表,用数据导出的三个不同方式合理高效的完成。比如数据库的被封任务可以做如下安排:

星期一:完全备份(A 星期二:增量导出(B 星期三:增量导出(C 星期四:增量导出(D 星期五:累计导出(E 星期六:增量导出(F 星期日:增量导出(G。

如果在星期日,数据库遭到意外破坏,数据库管理员可按一下步骤来回复数据库:第一步:用命令 CREATE DATABASE 重新生成数据库结构;第二步:创建一个足够大的附加回滚;第三步:完全增量导入 A :imp system/manager inctype=RESTORE FULL=y FILE=A 第四步:累计增量导入 E :imp system/manager inctype=RESTORE FULL=Y FILE=E 第五步:最近增量导入 F :imp system/manager inctype=RESTORE FULL=Y FILE=F 2.2 冷备份

冷备份发生在数据库已经正常关闭的情况下, 当正常关闭时会提供给我们一个完整的数 据库。冷备份时将关键性文件拷贝到另外的位置的一种说法。对于备份 Oracle 信息而言, 冷备份时最快和最安全的方法。冷备份的优点是:

1、是非常快速的备份方法(只需拷文件;

2、容易归档(简单拷贝即可;

3、容易恢复到某个时间点上(只需将文件再拷贝回去;

4、能与归档方法相结合,做数据库 “ 最佳状态 ” 的恢复;

5、低度维护,高度安全。但冷备份也有如下不足:

1、单独使用时,只能提供到 “ 某一时间点上 ” 的恢复;

2、再实施备份的全过程中,数据库必须要作备份而不能作其他工作。也就是说,在冷 备份过程中,数据库必须是关闭状态;

3、若磁盘空间有限,只能拷贝到磁带等其他外部存储设备上,速度会很慢;

4、不能按表或按用户恢复。

如果可能的话(主要看效率 , 应将信息备份到磁盘上, 然后启动数据库(使用户可以工作 并将备份的信息拷贝到磁带上(拷贝的同时,数据库也可以工作。冷备份中必须拷贝的文件 包括:

1、所有数据文件。

2、所有控制文件。

3、所有联机 REDO LOG文件。

4、Init.ora 文件(可选。

值得注意的使冷备份必须在数据库关闭的情况下进行, 当数据库处于打开状态时, 执行 数据库文件系统备份是无效的。

下面是作冷备份的完整例子:(1 关闭数据库;sqlplus /nolog sql>connect /as sysdba sql>shutdown normal;(2 用拷贝命令备份全部的时间文件、重做日志文件、控制文件、初始化参数文件 sql>cp。

(3 重启 Oracle 数据库 sql>startup。2.3 热备份

热备份是在数据库运行的情况下,采用 archivelog mode方式备份数据库的方法。所以, 如果你有昨天夜里的一个冷备份而且又有今天的热备份文件, 在发生问题时, 就可以利用这 些资料恢复更多的信息。热备份要求数据库在 Archivelog 方式下操作, 并需要大量的档案空 间。一旦数据库运行在 archivelog 状态下,就可以做备份了。热备份的命令文件由三部分组 成: 1.数据文件一个表空间一个表空间的备份:(1设置表空间为备份状态;(2备份表空间的数据文件;(3回复表空间为正常状态。2.备份归档 log 文件:(1临时停止归档进程;(2log下那些在 archive rede log目标目录中的文件;(3重新启动 archive 进程;(4备份归档的 redo log文件。

3.用 alter database bachup controlfile命令来备份控制文件: 热备份的优点是: 1.可在表空间或数据库文件级备份,备份的时间短。2.备份时数据库仍可使用。

3.可达到秒级恢复(恢复到某一时间点上。4.可对几乎所有数据库实体做恢复。

5.恢复是快速的,在大多数情况下爱数据库仍工作时恢复。热备份的不足是: 1.不能出错,否则后果严重;2.若热备份不成功,所得结果不可用于时间点的恢复;3.因难于维护,所以要特别仔细小心,不允许 “ 以失败告终 ”。3 系统数据库备份策略

数据库运行在归档模式下, 利用 Veritas 软件模块调用数据库的备份接口进行在线的热 备份, 可以在备份时,对备份数据保存在不同的存储对象中, 以满足客户容灾的要求, 可以 利用 Veritas 的多线程的数据迁移、利用多个磁带驱动器同时读写提高其数据备份的效率。针对数据库的总数据量和增量数据量大小, 我们可以利用数据库的多级的增量备份机制, 结 合 Veritas 强大的备份数据追踪寻址能力和介质管理功能,制定灵活的备份策略,实现全 自动的备份数据的全生命周期管理。

4备份系统数据库恢复策略

通过本地的 Veritas Server结合 Veritas for Databases利用备份数据进行数据恢 复。恢复时, Veritas 可以实现多线程的数据恢复,利用 Veritas 独特的磁带分类集中存 放技术,减少磁带的就位时间,提高数据恢复的效率。

先用最近一次的全备份恢复＋恢复最近一次的增量备份＋增量备份到断点的 ARCHIVE LOG 来恢复（要求数据库在 ARCHIVE LOG 模式下工作）。这种恢复方式比全部用 ARCHIVE LOG 恢复要快。如果两份冗余的最近一次增量备份都不可用，可以追溯再上次的增量备份来恢复，然后 用增量备份到断点的 ARCHIVE LOG 恢复。如果最近一次的全备份恢复都不可用,则利用上个周期的全备份＋上个周期的最后一次 增量备份＋本周期的最近一次增量备份＋增量备份到断点的 ARCHIVE LOG 来恢复。如果增量备份都不可用，那么用全备份＋ARCHIVE LOG 来恢复。5 数据库恢复可以分为以下两类： 5.1 实例故障的一致性恢复 当实例意外

地（如掉电、后台进程故障等）或预料地（发出 SHUTDOUM ABORT 语句）中 止时出现实例故障，此时需要实例恢复。实例恢复将数据库恢复到故障之前的事务一致状态。如果在在线后备发现实例故障，则需介质恢复。在其它情况 Oracle 在下次数据库起动时（对 新实例装配和打开），自动地执行实例恢复。如果需要，从装配状态变为打开状态，自动地 激发实例恢复，由下列处理：

（1）

为了解恢复数据文件中没有记录的数据，进行向前滚。该数据记录在在线日志，包括对回滚段的内容恢复。所指定的操作。

（2）回滚未提交的事务，按步 1 重新生成回滚段

（4）

（3）释放在故障时正在处理事务所持有的资源。

解决在故障时正经历一阶段提交的任何悬而未决的分布事务。5.2 介质故障或文件错误的不一致恢复 介质故障是当一个文件、一个文件的部分或磁盘不能读或不能写时出现的故障。文件错 误一般指意外的错误导致文件被删除或意外事故导致文件的不一致。这种状态下的数据库都 是不一致的，需要 DBA 手工来进行数据库的恢复，这种恢复有两种形式，决定于数据库运行 的归档方式和备份方式。（1）完全介质恢复可恢复全部丢失的修改。一般情况下需要有数据库的备份且数据库 运行在归档状态下并且有可用归档日志时才可能。对于不同类型的错误，有不同类型的完全 恢复可使用，其决定于毁坏文件和数据库的可用性。（2）不完全介质恢复是在完全介质恢复不可能或不要求时进行的介质恢复。重构受损 的数据库，使其恢复介质故障前或用户出错之前的一个事务一致性状态。不完全介质恢复有 不同类型的使用，决定于需要不完全介质恢复的情况，有下列类型：基于撤消、基于时间和 基于修改的不完全恢复。

基于撤消(CANCEL恢复：在某种情况，不完全介质恢复必须被控制，DBA 可撤消在指定 点的操作。基于撤消的恢复地在一个或多个日志组（在线的或归档的）已被介质故障所破坏，不能用于恢复过程时使用，所以介质恢复必须控制，以致在使用最近的、未损的日志组于数 据文件后中止恢复操作。

基于时间(TIME和基于修改(SCN的恢复：如果 DBA 希望恢复到过去的某个指定点，是 一种理想的不完全介质恢复，一般发生在恢复到某个特定操作之前，恢复到如意外删除某个 数据表之前。

6结 语 数据库的备份和恢复的主要工作就是为数据做了一份拷贝，防止出现故障时导致数据的 丢失。数据库受破坏一般是由于两种情况引起，其一为系统（软件）故障，如掉电、Server SQL 错误、操作系统错误、非正常关机等引起。其二为磁盘（介质）故障，由磁盘受破坏引起。若出现介质故障（如磁盘崩溃），当且仅当对数据库及事务日志做了定期备份，才能恢复数 据库。在实际应用中，应根据具体的情况，采纳一切可以用的方法，制定切合实际的备份和 恢复方案，明确在各种故障情况中数据可恢复的程度是否满足了应用的需要。为了保证数据 存储的可管理性，减少管理的复杂性，建立一个异地集中、在线的备份系统是必不可少的。采用先进的备份技术和先进的备份系统软件，采用统一的管理机制，保证大数据量的一致性 备份和高速切换。从而提供高效的存储设备的管理能力和可靠的数据备份功能。