系统应急预案及快速恢复方案.docx
- 文档编号:24383294
- 上传时间:2023-05-26
- 格式:DOCX
- 页数:23
- 大小:46.27KB
系统应急预案及快速恢复方案.docx
《系统应急预案及快速恢复方案.docx》由会员分享,可在线阅读,更多相关《系统应急预案及快速恢复方案.docx(23页珍藏版)》请在冰豆网上搜索。
系统应急预案及快速恢复方案
XXXX有限公司
XXX系统应急预案及快速恢复方案
20XX年11月
1.概述
1.1.目的
随着信息时代的到来,信息系统的使用在企业中涉及的业务范围与程度的不断深入,信息系统的安全、稳定运行尤为显得重要。
财务信息系统管理着企业的核心业务、财务和高度机密的数据,对企业的正常经营至关重要。
系统的安全正常运行是企业正常业务开展的前提与重要保障。
本方案从应急预案管理制度的建立、应急预案的流程制定和运作及其财务信息系统应急预案技术操作规范三个方面进行阐述,供企业在制定具体的应用软件系统运行管理应急预案时参考。
1.2.参考规定
1.3.应急情况分类
应急情况分重大灾难和一般性紧急情况两大类进行相应的处理。
1.3.1.重大灾难
重大灾难是指因各种不可抗力引起的系统灾难,主要有以下几个类型:
1、地震、火灾、雷电、水灾等自然灾害造成的破坏性突发事件;2、仪器设备被盗、机房存在重大安全隐患而造成的损失等严重突发事件;3、服务器系统崩溃、交换机等设备瘫痪、网络中断、病毒和黑客入侵;4、因大面积停电、外部网络中断等因素导致财务信息系统无法使用等不可抗力引起的网络瘫痪、设备毁损的重大灾难应急情况。
当财务信息系统及其运行环境(包括网络、硬件和支持软件)出现重大灾难时,启动重大灾难管理应急预案。
1.3.2.一般性的紧急情况
一般性的紧急情况指网络、设备、软件突发故障;人为小部分破坏、误操作、环境和应用系统突发瘫痪等引起的一般性应急情况。
当财务信息系统及其运行环境(包括网络、硬件和支持软件)出现一般性的紧急情况时,启动一般性的紧急情况管理应急预案。
2.应急预案及快速恢复方案管理制度
对于财务信息系统出现的紧急情况,企业的各部门应充分重视,参照本方案的条款制定相应的紧急预案及快速恢复方案管理制度:
2.1.工作原则
统一领导、统一指挥、各司其职、整体作战、发挥优势、保障安全。
对所发生的突发性事件,信息管理人员了解详细情况后,应马上向领导汇报。
2.2.组织领导
单位主要负责人为突发事件应急组组长,各相关业务经办机构负责人为副组长。
成员:
全体技术人员、每个业务经办机构选派一名业务骨干。
平时由信息管理部门会同各业务经办机构负责信息系统的安全管理工作,落实各项应急方案。
在遇到突发事件时,由突发事件应急组长宣布启动应急预案;
2.3.响应速度
当出现紧急情况,尤其是重大灾难事,突发事件应急组组长必须亲自到现场指挥和处理,工作人员接到通知后立即以最快的速度到达现场;
2.4.处理方式
严格按照财务信息系统紧急预案管理流程进行,具体操作规程按照财务信息系统紧急预案操作规范进行处理;
2.5.总结与报告
紧急事件处理完毕后应编写完整总结报告,总结报告应对事件发生的情况、处理过程和处理结果进行完整的记载和分析,向有关领导上报,并形成档案进行归档和管理。
2.6.应急处理程序及恢复控制原则
1 在数据库遭致破坏或损毁时,及时启动灾难性数据恢复操作规范,采用备份数据进行恢复,若建立了数据容灾系统,应迅即启用容灾备份系统支持正常业务开展。
2 在硬件损坏修复时,遵守数据安全完整第一原则,首先在保证存储介质不受损伤的情况下进行维修。
3 在不可预知灾难中造成数据缺损丢失或系统在近期内无法恢复时,应紧急启动手工业务处理预案。
在系统恢复过程期间,先采用手工处理相关业务。
4 局域网中断后,信息安全相关负责人员应尽快之内赶到机房,查明故障原因。
如属线路故障,应通知相关人员检修维护或重新安装线路。
如属路由器、交换机等网络设备故障,应立即从指定位置将备用设备取出接上,并调试通畅。
如属路由器、交换机配置文件破坏,应迅速按照要求重新配置,并调试通畅。
5 服务器等关键设备损坏后,值班人员应立即向信息安全负责人报告。
信息安全相关负责人员立即查明原因。
如果能够自行恢复,应立即用备件替换受损部件。
如属不能自行恢复的,立即与设备提供商联系,请求派维护人员前来维修。
6 如果设备和财务信息系统修复所需时间较长,应通过电话、网站、会议等方式做好宣传解释工作。
3.应急预案及快速恢复方案管理流程
当灾难性故障发生时,一般情况下对系统的破坏是全方位的,所以高层领导应充分重视,直接亲临现场指挥工作,运行环境应急处理、数据安全应急处理、系统应用应急处理同时进行。
当一般性应急事件发生时,可能对系统的破坏是部分的,部门领导应亲临现场领导和指挥工作,对具体影响进行分析和评估,制定并启动相应的应急方案。
下面对本方案的标准应急预案流程的各项工作进行说明:
3.1.应急情况的发现
工作内容:
当应急事件发生时,使用人员、网络管理员、系统管理员对事件的严重性进行初步判断后,应立即报告直接领导,如果是灾难性应急事件,应立即报告高层领导。
责任人:
使用人员、网络管理员、系统管理员。
工作成果:
必要时可进行书面汇报。
3.2.应急情况的评估
工作内容:
直接领导和高层领导会同使用人员、网络管理员、系统管理员对意外事件进行分析,对应急事件的严重性进行分析和评估,确定是重大灾难还是一般性紧急情况。
这是可以确定是否要求网络、设备、支持软件、财务信息系统的厂商提供立即到达现场提供服务。
责任人:
直接领导和高层领导。
工作成果:
对问题进行描述的书面文件。
3.3.应急情况的组织领导
3.3.1.重大灾难应急处理的组织领导
重大灾难故障的应急处理,应由高层领导召开现场会议,亲自指挥和安排工作。
3.3.1.1.召开现场会议
工作内容:
当被确定是重大灾难时应立即召开现场工作会议,组建一个临时工作小组,并安排工作内容,提出要求。
责任人:
直接领导和高层领导。
工作成果:
工作小组、工作内容、工作要求。
3.3.1.2.高层领导指挥
工作内容:
当被确定是重大灾难时高层领导应亲临现场指挥和监督工作。
责任人:
高层领导。
工作成果:
灾难解决
3.3.2.一般性紧急情况应急处理的组织领导
一般性紧急情况的应急处理,由部门领导亲自指挥和安排工作。
3.3.2.1.部门领导指挥
工作内容:
当被确定是一般性紧急情况时部门领导应亲临现场指挥工作,确定每个人的工作内容、工作要求。
责任人:
部门领导
工作成果:
工作内容、工作要求。
3.3.2.2.判断事件类型
工作内容:
部门领导应会同网络管理员、系统管理员、骨干用户进步对事件的影响程度进行分析和评估,确定事件对网络设备、系统软件、数据和应用系统的破坏程度。
责任人:
部门领导。
工作成果:
事件类型描述。
3.4.制定应急方案
3.4.1.数据安全应急方案
3.4.1.1.制定数据安全应急方案
工作内容:
系统管理员(必要时会同财务信息系统供应商)对系统数据的破坏程度进行分析制定数据安全应急方案,方案必须明确数据恢复数据库、时间点、那些(子)系统、责任人等,以及工作计划、安排和要求。
责任人:
系统管理员。
工作成果:
数据安全应急方案。
工作建议:
系统管理员如果对问题的具体定位有困难,在项目质保期内可要求项目乙方帮助处理。
3.4.1.2.执行数据安全应急方案
工作内容:
执行数据安全应急处理方案。
责任人:
系统管理员。
工作成果:
问题已经处理,并对处理过程进行详细记录。
工作建议:
系统管理员如果对问题的处理有困难,在项目质保期内可要求项目乙方帮助处理。
3.4.2.应用系统应急方案
3.4.2.1.制定系统应用应急方案
工作内容:
系统管理员(必要时会同财务信息系统供应商)对财务信息系统的破坏程度进行分析制定应用系统应急方案,方案必须明确系统恢复的内容、时间要求、责任人等,以及工作计划、安排和工作要求。
责任人:
系统管理员。
工作成果:
应用系统应急方案。
工作建议:
系统管理员如果对问题的具体定位有困难,在项目质保期内可要求项目乙方帮助处理。
3.4.2.2.执行系统应用应急方案
工作内容:
执行数据安全应急处理方案。
责任人:
系统管理员。
工作成果:
问题已经处理,并对处理过程进行详细记录。
工作建议:
系统管理员如果对问题的处理有困难,在项目质保期内可要求项目乙方帮助处理。
3.5.总结报告
工作内容:
当应急事件处理完毕后部门领导必须就本次事件的发生原因、处理过程、处理结果、经验和教训进行书面总结,并向企业的有关领导和有关用户进行汇报。
责任人:
部门领导。
工作成果:
应急事件处理报告。
3.6.记录并归档管理
工作内容:
同时部门领导应将“应急事件处理报告”进行有关归档管理的处理,以备以后查用。
责任人:
部门领导。
工作成果:
归档管理的“应急事件处理报告”。
4.应急预案及快速恢复方案技术操作规范
4.1.运行环境应急预案及快速恢复方案技术操作规范
运行环境包括网络、硬件、操作系统和支持软件等,下面叙述其急预案技术操作规范:
4.1.1.网络应急管理规范
4.1.1.1.情况描述
网络系统,包括保障系统运行的局域网、广域网和相关的网络设备出现故障或可靠性严重下降时,视为紧急情况。
4.1.1.2.应对方案
(1)在力所能及的职权范围内,启动本管理流程:
推荐采用冗余网络。
中心服务器到下属单位的之间平常使用电力城域网连接,另外可考虑使用电信的ADSL或DDN专线,通过加密的VPN设备形成第二条辅助的VPN专网。
当电力网络繁忙或出现故障时,用户客户端可通过辅助网络连接。
从而不影响正常业务工作。
(2)网络方面如下应急方案:
●当客户端连接服务器时,经过长时间等待后,报服务连接失败的错误。
此时有可能是网络不通。
请按如下步骤操作:
首先请尝试ping本地局域网的其它计算机,如果不通,请联系相关部门及时处理;如果能连通,请ping总部的应用服务器;如果能通,则可能属于软件系统的故障,寻求软件实施商的帮助;如果不通,可能是总部网络故障;请求总部相关的系统管理员解决,并启用备用网络连接。
●当客户端连接时,出现了数据库连接失败的提示时,请按如下步骤操作:
●请ping数据库服务器,如果不通,可能是数据库群集的网络出现故障,请求总部相关的系统管理员解决。
如果能连通,可能是数据库故障。
●要考虑对网络设备的冗余,对网络设备进行备份,主要是对交换机、防火墙、路由器等设备采用备份策略,解决网络设备的单点故障,保证网络可靠的运行。
●根据网络设备的售后服务协议,及时进行维修。
●如果是线路故障,也要及时通知有关部门进行维修。
4.1.2.服务器和其他硬件应急管理规范
4.1.2.1.情况描述
数据库服务器、中间件服务器、域控制器等硬件设备出现故障时,视为紧急情况。
4.1.2.2.应对方案
(1)如果是一个硬件服务器出现故障时,系统将瘫痪,如果系统是热备或群集,当发现出现其中一个硬件服务器出现问题时,系统虽能工作,但都要及时的启动本流程。
(2)硬件在购置时应建立完善的售后服务体系;
(3)问题具体定位后,应及时联系产品供应商进行处理。
(4)由此引发的服务系统的安装应及时启动“系统应用应急”和“系统数据处理应急”等相关应急处理流程。
4.1.3.数据库管理系统应急管理规范
4.1.3.1.情况描述
数据管理系统包括数据库服务器、客户端及其相关的管理工具出现崩溃的紧急情况。
4.1.3.2.应对方案
(1)如果是一个数据库系统,系统将瘫痪,如果数据库系统是热备或群集,当发现出现其中一个出现问题时,系统应能工作,无论那种情况,都要及时的启动本流程。
(2)这些系统在购置时应建立完善的售后服务体系;
(3)问题具体定位后,核实是否在供应商应该提供相应的服务,如果在服务范围之内及时联系产品供应商进行处理。
(4)核实项目软件的实施商是否应该提供相应的技术服务,如果在服务范围之内及时联系项目实施商进行处理。
4.1.4.中间件管理系统应急管理规范
4.1.4.1.情况描述
中间件管理系统包括WEB服务器、J2EE服务器、消息服务器和邮件服务器等方面的软件系统出现崩溃时的紧急情况。
4.1.4.2.应对方案
(1)这些系统在购置时应建立完善的售后服务体系;
(2)当出现问题时,启动本管理流程;
(3)问题具体定位后,核实是否在供应商应该提供相应的服务,如果在服务范围之内及时联系产品供应商进行处理。
(4)核实项目软件的实施商是否应该提供相应的技术服务,如果在服务范围之内及时联系项目实施商进行处理。
4.1.5.其他软件系统应急管理规范
4.1.5.1.情况描述
其他软件系统包括磁盘阵列、磁带库、集群、安全管理等方面的软件系统出现崩溃时的紧急情况。
4.1.5.2.应对方案
(1)这些系统在购置时应建立完善的售后服务体系;
(2)当出现问题时,启动本管理流程;
(3)问题具体定位后及时联系产品供应商进行处理。
4.2.数据安全应急预案及快速恢复方案技术操作规范
当应急事件出现时,对系统的数据库已经造成了破坏,例如服务器坏了,或者被盗了,或者崩溃了,总之,就是不能使用了,我们必须重新安装数据库系统,从最近的备份点进行恢复数据,所以没有备份就无从恢复,可见备份是至关重要的,基于其重要性和ORACLE数据库系统应用的广泛性,在此首先说明一般的备份和恢复的技术规范后,重点重申ORACLE数据库的备份规范,然后再说明数据库恢复规范。
4.2.1.数据库系统的备份一般规范
一个好的备份系统,除了需要配备有好的软硬件产品之外,更需要有良好的备份策略和管理规划来保证备份系统的QOS。
建立备份策略时,要统筹考虑需备份的数据总量,线路带宽、数据吞吐量、时间窗口以及对恢复时间的要求等因素。
目前的备份策略主要有全备份、增量备份和差异备份。
全备份所需时间最长,但恢复时间最短,操作最方便,当系统中数据量不大时,采用全备份方式最为可靠。
增量备份和差异备份所需的备份介质和备份时间都较全备份少,但是数据恢复烦琐。
根据不同业务对数据备份的备份窗口和灾难恢复的要求,可以选择不同的备份方式,亦可以将这几种备份方式进行组合应用,以得到更好的备份效果。
4.2.1.1.备份类型
全备份(FullBackup),所谓全备份,就是对整个系统包括系统文件和应用数据进行的完全备份。
这种备份方式的优点是数据恢复所需时间短。
缺点是备份数据中有大量内容是重复的,这些重复的数据浪费了大量的磁带空间,无形中增加了数据备份的成本;此外,由于需要备份的数据量大,因此备份所需时间相对较长。
一般数据量情况下,半个小时左右时间可以完成全库的恢复,恢复过程需要离线进行,即这段时间内系统不可用。
而在线备份可能要花费1到数小时。
增量备份(IncrementalBackup),增量备份指每次备份的数据是上一次备份后增加和修改过的数据。
这种备份的优点很明显:
没有重复的备份数据,节省磁带空间,又缩短了备份时间。
但它的缺点在于当发生灾难时,恢复数据比较麻烦,需进行多次数据恢复才能恢复至最新的数据状态。
这种备份恢复的时间跟数据的更改量有关系,最快的可能1天的增量数据2分钟就备份/恢复完成,一般需要10-数十分钟。
差异备份(DifferentialBackup),差异备份就是每次备份的数据是相对于上一次全备份之后新增加的和修改过的数据。
差异备份无需每次都做系统完全备份,因此备份所需时间短,并节省磁带空间;另外,差异备份的灾难恢复也很方便,系统管理员只需做两次备份数据,即全备份的数据磁带与发生灾难前一天的备份数据磁带,就可以将系统完全恢复。
这种方式的数据量和所需时间介于上述两种方式之间。
4.2.1.2.备份周期
建议每周作一次完全备份,保存周期为一个月;
将每月未的完全备份进行保存,周期为一年(可以更长),有带库的情况下建议保存10年;
每天作一次增量备份,保存周期为一个月。
4.2.1.3.恢复方式
恢复时首先恢复最近一次的全备份,然后再恢复所有的增量备份。
4.2.2.ORACLE数据库系统的备份
4.2.2.1.备份范围
描述oracle数据库备份范围,一般包括控制文件、在线重做日志文件、归档日志文件、数据文件等。
范例:
(1)控制文件
控制文件是数据库中非常重要的部分,控制文件与数据库的物理结构有关,记录了数据库名和数据库的唯一标识DBID,以及全部数据文件名及路径、全部的日志文件名及路径,数据库恢复所需的同步信息也存储在控制文件中。
因此,对于实际运行的数据库,控制文件必须要进行镜像。
三个控制文件分别放在三个不同的磁盘上。
(2)在线重做日志文件
在线重做日志文件是保证数据库安全,以及与数据库备份与恢复有直接关系的文件,日志文件损坏或日志信息的丢失,比数据文件损坏对于数据安全的影响更大,因为某一个日志文件的损坏,可能导致整个数据库不能使用。
因此,为了防止日志文件的物理损坏,要对日志成员进行镜像,镜像的日志成员文件存储与不同的物理磁盘。
(3)归档日志文件
归档日志即重做日志的备份,使用归档日志的目的是为了实现介质恢复。
其对数据库恢复有很重要的作用,因此也需要对归档日志进行镜像。
(4)数据文件
数据文件是用于存储数据库数据的文件,为了保证数据安全,将数据文件存放在RAID5磁盘阵列上。
4.2.2.2.文件存放策略
综合以上要求,同时考虑性能因素、数据安全因素,
(1)建议对重做日志组进行以下配置:
设八组日志组,每组大小为100M;
由于重做日志文件对写性能要求比较高,建议使用8块硬盘做两组RAID10磁盘阵列,每组4块盘;
每组两个日志文件,分别放在两组RAID10磁盘阵列上。
(2)建议对控制文件按以下方式进行存放:
两个控制文件分别存放在两组RAID10磁盘阵列上;
第三个控制文件存放在RAID5磁盘阵列上。
(3)建议对归档日志文件按以下方式进行存放:
将归档日志文件和镜像文件分别存放在两组RAID10磁盘阵列上。
(4)建议将数据文件存放在RAID5磁盘阵列上。
4.2.2.3.备份方法
数据库的备份与恢复是保证数据库安全运行的一项重要内容,也是数据库管理员的重要职责。
在实际中,如果数据库发生灾难性破坏,例如,由于数据库的物理结构被误操作破坏或由于机器硬件故障而遭到破坏,必须使用数据库的备份文件对数据库实施及时的恢复,尽可能使用户的数据免遭损失,使数据库正常运行。
下面以RMAN备份为例进行说明,其他第三方备份工具不再进行列举,备份策略相同。
4.2.2.3.1.RMAN备份的特点
采用数据库提供的RMAN备份工具有以下的优点:
(1)支持在线热备份
在线热备份是指备份不需要关闭数据库进行,在备份的同时可以进行正常的数据库的各种操作,满足了7*24的系统的需要,数据库的备份将不会影响INTERNET或INTRANET用户对数据库的访问。
(2)支持多级增量备份
多级增量备份是指第N级的备份只需要备份最后一次同级或N-1级备份以后发生的改变的数据。
可以通过下图来说明:
上图是一个增量备份的例子,即在第一个星期天做一个增量的0级备份,然后在星期一,星期二做一个增量的2级备份,在星期三做一个增量的1级备份,然后类推。
假设现在在星期五数据库需要做恢复,则可以先恢复第一个星期天的0级备份,,然后恢复星期三的1级备份,再恢复星期四和星期五的2级备份就可以完成数据库的恢复。
(3)支持并行备份,恢复
并行备份,恢复,RMAN是通过启动数据库的SERVER进程来进行备份和恢复,而且支持启动多个SERVER进程来进行备份和恢复,在同一个SERVER进程内还支持多个BACKUPSET(备份集)的同时产生。
主要是通过设置多个通道及filesperset参数来达到并行的目的。
分配多个通道的语句(以下语句分配两个通道)
Allocatechannel‘dev_1’typedisk;
Allocatechannel‘dev_2’typedisk;
减小所需要备份量
减少所需要的备份数据量,因为RMAN是工作在数据块一级,所以能够只备份分配的数据块,这样就大大地减少了所需要的备份的数据量,特别是对于预先分配空间的数据库而言。
(5)备份,恢复使用简单
使用简单,RMAN的使用特别简单,在进行备份和恢复时都不需要指定需要备份或需要恢复的数据文件,RMAN会自动地把备份或恢复所需要的数据文件进行备份或进行恢复。
减少了人为操作可能产生的错误。
4.2.2.3.2.RMAN配置方法
配置RMAN包括配置CATALOG数据库,制定RMAN的多级备份方案,写RMAN备份脚本。
(1)配置CATALOG数据库
CATALOG数据库
因为RMAN自动维护备份和恢复所需要的各种信息,所以RMAN必须把这些以某种形式保存。
RMAN支持两种形式保存这些信息,数据库的控制文件或创建一个单独的数据库来保存RMAN的信息。
当选择把RMAN的信息存储在控制文件时,控制文件的丢失时将导致备份将不能进行恢复。
所以若采用RMAN做备份,推荐一定采用RMANCATALOG数据库来单独存放备份信息。
这个单独的数据库(称为CATALOG数据库)只需要很小的空间,既可以和被备份的数据库(E10K)放在同一主机上,也可以单独放在另一台主机上(如果条件允许,推荐放在一台单独的主机上来确保最大的可恢复性)。
备份CATALOG数据库
因为CATALOG数据库包含了所有的备份信息,所以该数据库本身也是需要通过某种方法进行备份,但因为该数据库很小(一年内可能才增加十几二十兆),所以既可以对它进行冷备份,也可以进行逻辑的输出(EXPORT)。
配置CATALOG数据库
●用dbassist创建数据库。
●在该数据库创建RMAN数据库用户
createuserrmanidentifiedbyrmandefaulttablespacets_rman
temporarytablespacetemp;
grantconnect,resource,RECOVERY_CATALOG_OWNERtorman.
●连接到目标数据库和CATALOG数据库
rmantargetsystem/manager@target_tnsnamercvcatrman/rman@catalog_tnsname
●创建CATALOG用户的表:
rman>createcatalog
●登记目标数据库:
rman>registerdatabase
这样就可以利用该RMAN数据库来备份目标数据库了。
●磁带接口
当使用专用的磁带管理工具时,必须配置数据库与磁带的接口,一般是管理工具提供一个动态连接库与数据库进行连接。
●进行测试
以下是一个测试的RMAN脚本
run{
allocatechannel'dev1'typedisk
resynccatalog;
backupformat‘/archive/ctl%u_%p_%c‘currentcontrolfile;
releasechanneldev1}
(2)多级备份策略
采用多级备份是为了减少了恢复所需要的时间和减少每天备份所需要的时间,而又保证系统有很好的恢复性。
但是在恢复时间和备份时间要有一个权衡。
比如只要开始的一个全备份和备份所有产生的归档文件就可以保证把数据库恢复到最新的状态,但是一般来说实际上并不会这么进行(因为在恢复时将需要很长很长的时间),多级备份就是为了解决这样的问题。
以下是一种建议的方案:
●在第一个星期天做一个增量的0级备份,同时将备份集备份在磁带上;
●在星期一,星期二做一个增量的2级备份;
●在星期三做一个增量的1级备份;
●在星期四、星期五、星期六做一个增量的2级备份;
●当需要时(如十二个小时归档文件系统就要接近满了)备份归档文件;
●假设现在在星期五数据库需要做恢复,则可以先恢复第一个星期天的0级备份,然后恢复星期三的1级备
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 系统 应急 预案 快速 恢复 方案