linux之间实现db2异机备份还原总结.doc

数据库备份还原测试：思路：将数据库服务器（32.74.4.125）中数据库(bras)备份到归档服务器（32.74.4.123）上-说明：准确的说是备份到挂载在归档服务器（32.74.4.123）上的归档设备上，归档设备的挂载点为/mnt/efile步骤：一. 实现共享服务 由于数据库服务器和归档服务器都是linux系统故而使用nfs共享 将归档服务器当作nfs共享服务器端（server），数据库服务器作为客户端（client） 1. nfs共享服务器端配置： 1> 配置文件/etc/exports-测试成功20101112 使用vi /etc/exports在其中添加/mnt/efile/dbbak 32.74.4.*(rw,sync,no_root_squash)解释：表示共享服务器上的/mnt/efile/dbbak目录只有符合32.74.4.xxx的主机可以访问ro: 只读权限rw: 读写权限sync:资料同步写入到内存与硬盘中async:资料会先暂存与内存中，而非直接写入硬盘root_squash:客户机用root用户访问该共享文件夹时，将root用户映射成匿名用户no_root_squash:客户机用root用户访问该共享文件夹时，不映射root用户all_squash:客户机任何用户访问该共享文件夹时，将映射成匿名用户insecure:允许从这台机器过来的非授权访问anonuid:将客户机上的用户映射成指定的本地用户ID的用户anongid:将客户机上的用户映射成属于指定的本地用户组ID 2> 启动nfs后又修改了/etc/exports,不用重启该服务，使用exports命令即可：exports -aruv-a: 全部mount或umount文件/etc/exports中的内容-r: 重新mount文件/etc/exports中的共享内容-u: umount目录-v: 在export的时候，将详细的信息输出到屏幕上 2. 客户端配置1. 挂载共享目录：-测试成功20101112mount -t nfs -o rw 32.74.4.123:/mnt/efile/dbbak /mnt/dbbak2. 实现客户机开机自动挂载服务器的共享目录-测试失败20101112-20101116 方法1：修改/etc/fstab文件,格式如下：32.74.4.123:/mnt/efile/dbbak /mnt/dbbak nfs defaults 0 2fs_spec fs_file fs_type fs_options fs_dump fs_passfs_spec:定义希望加载的文件系统所在的设备或远程文件系统，对于nfs则设为IP:/共享目录fs_file:本地挂载点fs_type:挂载类型fs_options:挂载参数fs_dump:该选项被dump命令使用来检查一个文件系统该以多块频率进行转储，若不需转储即为0fs_pass:该字段被fsck命令使用来决定在启动时需要被扫描的文件系统的顺序，跟文件系统“/”对应该字段值为1，其他文件体统为2，若该文件系统无需在启动时被扫描即为0 方法2：-测试失败20101112-20101116修改/etc/rc.local文件，添加如下语句：mount -t nfs -o rw 32.74.4.123:/mnt/efile/dbbak /mnt/dbbak 方法3：-测试成功20101116在/etc/profile文件中添加如下语句：mount -t nfs -o rw 32.74.4.123:/mnt/efile/dbbak /mnt/dbbak1> 修改/etc/rc.local文件，添加如下语句：-测试成功20101116mount -t nfs -o rw 32.74.4.123:/mnt/efile/dbbak /mnt/dbbak2> 编写shell脚本/mnt/mount123.sh，内容如下：-测试成功20101116mount -t nfs -o rw 32.74.4.123:/mnt/efile/dbbak /mnt/dbbak修改/etc/rc.local文件，添加如下语句：/mnt/mount123.sh如果这样还自动挂载失败的话，可以执行如下语句，为/etc/rc.local添加一个链接ln -sf /etc/rc.local /etc/rc3.d/S99local-说明：1. 方法1和方法2在测试的时候都是失败的，不过我在VMware虚拟机(Ubuntu10.04)上使用方法1和方法2则是成功的，而在Red Hat Enterprise Linux Server release 5.3上边则失败。个人认为是系统的问题。有的时候，同一个版本的系统，有的成功，有的失败，我只能够说人品差了点。2. 方法3其实是在方法2的基础上实现的，在/etc/profile中添加如上面添加的语句，这还是我自己经过一段时间的摸索测试得出的结论虽然有些坎坷，不过不管怎样最后还是成功的实现开机启动（自动挂载），值得高兴。至此，文件共享已完成二. 数据库备份 思路：要能够实现自动备份：每周六进行在线完全备份一次，其他工作日每天进行在线增量备份一次 以下备份测试均为在测试环境（测试数据库：32.74.4.124）上进行（为了保险起见，呵呵，要不生产环境上稍微出点问题就麻烦了）： 1. 测试是否能够将数据库备份通过挂载点直接备份至归档服务器上-测试成功20101112 测试语句：db2 backup db bras online to /mnt/dbbak 2. 在/mnt/efile/dbbak下边新建bak,dbarclog文件夹，完全备份存放于dbbak下，bak用于存放增量备份，dbarclog用于存放归档日志 编写shell脚本fullbackup.sh和incrementalbackup.sh,两个脚本放在/mnt/下 fullbackup.sh:/opt/ibm/db2/V9.1/bin/db2 backup db bras online to /mnt/dbbak incrementalbackup.sh:/opt/ibm/db2/V9.1/bin/db2 backup db bras online incremental to /mnt/dbbak/bak 编写以上两个shell是为了方便使用crontab自动在bras用户下：crontab -e-每周六18点执行完全备份* 18 * * 6 /mnt/fullbackup.sh>>/tmp/fullbackup.log -测试成功20101115-每周除周六外的其他工作日的21点执行增量备份* 21 * * 0-5 /mnt/incrementalbackup.sh>>/tmp/incrementalbackup.log -测试成功20101115crontab -l 查看当前用户下的crontab任务修改之后，用root用户执行crontab -u bras /var/spool/cron/bras使bras用户的crontab生效1> -修改数据库参数，使之支持在线联机备份 db2 update db cfg for bras using logretain on trackmod on2> -可以指定归档日志的存放路径，如将其存入/mnt/dbbak/dbarclog下，脚本如下： db2 update db cfg for bras using logarchmeth1 disk:/mnt/dbbak/dbarclog3> 以上备份策略是在logretain、trackmod都为on的情况下，即采用归档日志的情况，还原时需要回滚日志。如果采用循环日志，即trackmod为on，logretain为off的情况,参数修改之后，与数据库相连的所有应用断开了，修改才会生效.此时，数据库处于暂挂状态，需要做一次离线备份。4> -执行增量、在线备份之前必须执行离线全备份一次，否则数据库将处于备份暂挂的不可用状态(联机完全备份)db2 backup db bras to /mnt/dbbak-在线：db2 backup db bras online to /mnt/dbbak5> -执行联机备份，备份同时再打开一个会话，模拟应用在线(联机增量备份)db2 backup db bras online incremental to /mnt/dbbak/bak三.数据库还原-模拟灾难，删除数据库!-重要，此前一定要将活动日志文件备份至另一个路径，保存好，本例中，活动日志保存在 /db2data/db2log 下。-db2 get db cfg for bras 可找到日志存放路径，将其下所有日志文件备份至另一个路径保存db2 drop db bras -根据在线完全备份恢复数据库db2 restore db bras from /mnt/dbbak taken at 完全备份时间戳记-根据在线增量备份恢复数据库 db2 restore db bras incremental automatic from /mnt/dbbak/bak taken at 增量备份时间戳记-恢复后的数据库处于前滚暂挂的不可用状态db2 connect to bras -前滚数据库，并指定归档日志位置，重要! db2 ROLLFORWARD DATABASE bras TO END OF LOGS AND COMPLETE OVERFLOW LOG PATH ("/db2data/db2log")说明： 默认情况下只能对数据库进行离线（脱机）备份，备份时需要断开与备份数据库相连接的进程 我们一次性修改logretain 、trackmod、userexit 为 on 状态，因为实际应用中多以在线完全备份、在线增量备份为主，此时可以进行任何一种备份。需要强调的是，只要启用了归档日志（logretainon），就可以进行在线备份，而此时不论是在线备份还是离线备份，还原数据库时都需要回滚日志，才能恢复正常，为此对日志（特别是活动日志）的保存值至关重要的。只要启用了trackmodon，就可以进行增量备份（累计增量备份和delta增量备份）。如果采用delta增量备份，还原时还要注意还原的顺序（使用automatic让系统自动检索还原顺序自动还原数据库）。备份还原测试得到的结论： 备份：1. 第一次全量备份编号为1，多次增量备份编号分别为2,3,4,5,6,7,82. 将编号为2,3,4,5,6,7的增量备份删除3. copy数据库日志文件至另一个目录，再drop数据库 还原：1. 首先，还原编号为1的全量备份2. 然后，还原编号为8的增量备份（还原增量备份时，若删除了某些增量备份，则需要要使用关键字automatic，否则在执行回滚操作时，会失败，并提示SQL1119N 因为先前复原不完整或者仍在进行，所以不能连接或激活数据库 "TESTDB"。SQLSTATE=57019）3. 执行rollforward操作