test

Sun Java System Calendar Server 6.3 管理指南

22.5.8 恢复自动备份副本

如果已使用第 9 章，配置自动备份中所述的自动备份功能，则可以在动态数据库损坏时使用紧急备份副本。

本节介绍了如何恢复两个不同的自动备份：

22.5.8.1 恢复之前

在恢复备份之前，请确保您已经执行了以下操作：

Procedure恢复紧急备份

当动态数据库损坏时，紧急备份应当是首选的备份。要恢复紧急备份，请执行以下步骤：

  1. 标识损坏的动态数据库目录中的任何未应用或为写入而打开的日志文件。

  2. 关闭为写入打开的日志。它包含最新事务。

  3. 创建新的（恢复）目录。

  4. 将当前紧急备份副本复制到新的恢复数据库目录中。

  5. 将 log.* 文件从损坏的动态数据库目录中复制到新的恢复数据库目录中。

  6. 如果您要保留数据库的归档副本，请将尚未应用到动态数据库的日志复制到归档目录中，这样归档备份副本就完整了。

  7. 针对新的恢复数据库运行 db_recover，同时指定 -c -h 选项。

    例如，如果新的恢复目录名为 recoverydb，则命令将如下所示：

    db_recover -c -h recoverydb

  8. 将 log.* 文件保留在新的恢复目录中。

    db_recover 程序将日志文件应用到新的恢复数据库，但是从 4.2 版开始，Berkeley DB 要求保留这些日志文件。

  9. 针对新的恢复目录中的数据库文件运行 db_verify。运行 db_verify：

    1. 使用这些命令停止 Calendar Server。

      cd /opt/SUNWics5/cal/sbin

      ./stop-cal

    2. 使用此命令创建 Calendar Server 数据库 (csdb) 的另一个副本。

      cp -Rp /var/opt/SUNWics5/csdb /var/opt/SUNWics5/csdb.db_verify

    3. 针对 csdb 的副本运行 db_verify。

      注 –

      请勿针对初始 csdb 运行 db_verify。

      LD_LIBRARY_PATH=/opt/SUNWics5/cal/lib
export LD_LIBRARY_PATH
cd /opt/SUNWics5/cal/tools/unsupported/bin
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50alarms.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50calprops.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50events.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50gse.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50journals.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50recurring.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50todos.db
./db_verify -o -h /var/opt/SUNWics5/csdb.db_verify ics50deletelog.db
      注 –

      针对 ics50deletelog.db 运行 db_verify，同时带上 -o 选项。

      如果成功运行完成 db_verify，则不会收到任何错误消息。如果数据库文件已损坏，它会抛出错误消息。例如：


      ./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50todos.db
db_verify:Page 612: last item on page sorted greater than parent entry
db_verify: Page 612: incorrect next_pgno 885 found in leaf chain (should be 501)
db_verify: Page 0: page 501 encountered a second time on free list
db_verify: DB->verify: ics50todos.db: DB_VERIFY_BAD: Database verification failed

  10. 针对新的恢复目录运行 csdb -v list。

  11. 如果新的恢复目录通过了上述全部三个恢复步骤，则损坏的旧动态数据库将替换为新的恢复数据库。

  12. 将新的动态数据库复制到紧急备份目录中以用作新快照。

    所有新的日志都将应用到此副本中，直到拍下了下一个定期快照。

  13. 启动 Calendar Server。

  14. 如果新的恢复目录在任何一个步骤失败，则按如下所述确定未损坏的早期紧急备份：

    1. 从新到旧依次对每个紧急备份运行 db_verify 和 csdb -v list，以找到最近一个未损坏的副本。

    2. 可以将第一个找到的无损紧急备份副本恢复到动态数据库目录中。

      用未损坏的紧急备份替换损坏的动态数据库，如恢复紧急备份所述。（请确保首先阅读22.5.8.1 恢复之前。）

    3. 如果所有紧急备份均已损坏且没有可供恢复的归档备份，请致电技术支持。如果具有归档备份，请执行恢复归档备份中的过程。（另请参见22.5.8.1 恢复之前。）

Procedure恢复归档备份

如果您没有未损坏的紧急备份，但有归档备份及其事务日志，则可以通过执行以下步骤来恢复最近未损坏版本的已归档数据库：

  1. 标识损坏的动态数据库目录中的任何未应用或为写入而打开的日志文件。

  2. 关闭为写入打开的日志。它包含最新事务。

  3. 创建新的（恢复）目录。

  4. 将最新的归档副本及其日志文件复制到新的恢复数据库目录中。

  5. 将任何未应用的 log.* 文件从已损坏的动态数据库目录复制到新的恢复数据库目录中。

  6. 针对新的恢复数据库运行 db_recover，同时指定 -c -h 选项。

    例如，如果新的恢复目录名为 recoverydb，则命令将如下所示：

    db_recover -c -h recoverydb

  7. 将 log.* 文件保留在新的恢复目录中。

    db_recover 程序将日志文件应用到新的恢复数据库中，但是从 4.2 版开始，Berkeley DB 要求保留这些日志文件。

  8. 针对新的恢复目录中的数据库文件运行 db_verify。

    恢复紧急备份过程中的步骤说明了如何运行 db_verify。

  9. 针对新的恢复目录运行 csdb -v list。

  10. 如果新的恢复目录通过了上述全部三个恢复步骤，则损坏的旧动态数据库将替换为新的恢复数据库。

  11. 将新的动态数据库复制到紧急备份目录中以用作新快照。

  12. 启动 Calendar Server。

  13. 如果新的恢复目录在任何一个步骤失败，则标识未损坏的早期归档备份，如下所述：

    1. 依次从新到旧对每个归档备份副本运行以下三个恢复程序，以找到最近一个未损坏的副本：db_recover -c-h、db_verify 和 csdb -v list。

    2. 可以将第一个找到的无损归档副本恢复到动态数据库目录中。

      用未损坏的归档备份替换损坏的动态数据库，如恢复归档备份所述。

    3. 如果所有的归档备份均已损坏，请致电技术支持。