Sybase 数据库备份与恢复策略

dbaai

Sybase ASE 数据库备份与恢复策略：从 dump 到 online 的完整闭环

一、具体的问题

不少刚接手 Sybase ASE 的 DBA，把"备份"理解成偶尔手动敲一条 dump，真到出问题要恢复时，才发现备份链断了一截、事务日志没单独备、或者恢复完库起不来。本文聚焦一个最实在的问题：怎么设计一套"全量 + 日志"的备份策略，让任何时间点都能把库拉回可用状态，并且恢复步骤可照做、不靠运气。

二、核心原理

1. DUMP 与 LOAD 是 ASE 的官方备份通道

Sybase ASE 不靠操作系统拷贝数据文件来备份，而是用 dump database（整库全量）和 dump transaction（事务日志增量）。它们生成的是数据库一致性镜像，恢复时用 load database + load transaction 顺序回放，最后 online database 让库可见。

2. 为什么要单独备事务日志

全量 dump 之间总有时间差。如果只做全量，RPO（恢复点目标）就是两次全量之间的间隔，可能丢几小时数据。把事务日志按 15~30 分钟频度单独 dump，就能把 RPO 压到分钟级。前提是被备份库必须开启 trunc log on chkpt 关闭、并允许日志独立转储——也就是 sp_dboption <db>, 'trunc log on chkpt', false。

3. 备份链必须连续

load 的顺序是固定的：先 load 最近一次全量，再按时间顺序依次 load 每段事务日志，最后 online。中间缺一段，后续日志就接不上。所以备份脚本要按"全量日 + 日志每 N 分钟"排好，并把每次 dump 的文件名带上日期时间戳，方便按序排列。

4. 一个常见的翻车现场

某业务库平时只周末做全量 dump，平时从不做事务日志转储。周三下午磁盘损坏，最近一次可用备份是上周日，直接丢了三天数据，且 trunc log on chkpt 一直开着，连补救的日志都没有。这就是"备份策略缺失"的典型后果。

三、实例参考（动手步骤）

下面给出一套可在测试库直接照做的"全量 + 日志 + 恢复"流程。假设测试库名为 testdb。

1) 先确认该库允许单独转储事务日志（关闭自动截断）：

2. exec sp_dboption 'testdb', 'trunc log on chkpt', false
3. exec sp_dboption 'testdb', 'select into/bulkcopy', true

复制代码

2) 做首次全量 dump，文件名带日期：

2. dump database testdb
3.   to '/sybdump/testdb_full_20260831.dmp'
4.   with compression = 1
5. go

复制代码

3) 模拟白天业务写入后，按 30 分钟频度转储事务日志（生产中由定时任务循环执行）：

2. dump transaction testdb
3.   to '/sybdump/testdb_tran_20260831_0800.dmp'
4. go

复制代码

4) 灾难恢复：先 load 全量，再按序 load 各段日志，最后 online：

2. load database testdb
3.   from '/sybdump/testdb_full_20260831.dmp'
4. go
5. load transaction testdb
6.   from '/sybdump/testdb_tran_20260831_0800.dmp'
7. go
8. online database testdb
9. go

复制代码

5) 验证恢复结果：用 sp_helpdb testdb 看状态是否变成 online，连接进去 select count(*) from 关键表 核对行数是否和预期一致。

前后对比：恢复前该库因磁盘损坏完全不可访问（业务停写）；按上述链恢复后，数据回到最近一次日志 dump 时间点，RPO 从"三天"降到"30 分钟"，业务在分钟级内重新可读写。

四、实操检查清单

• 被备份库是否已关闭 trunc log on chkpt，确保事务日志能单独转储？
  
• 全量 dump 与事务日志 dump 是否用带日期时间戳的文件名，方便按序排列与归档？
  
• 事务日志转储频度是否满足业务 RPO 要求（建议 15~30 分钟一次）？
  
• 备份文件是否写到独立于数据库磁盘的存储，避免同盘损坏一起丢？
  
• 是否定期做"恢复演练"：在一台备用机上 load 全量 + 日志，验证备份链可用？
  
• 恢复前是否有人值守核对 dump 文件时间顺序，避免漏 load 某段日志？
  
• online database 之后是否验证库状态为 online、关键表行数正确？
  
• 是否保留至少两份全量 + 完整日志链（N 份异地更佳），防止单份损坏？
  
• 大库是否启用 dump ... with compression 控制备份体积与 IO？
  
• 是否把备份任务接入监控，dump 失败（磁盘满/权限不足）能及时告警？
  

五、一点经验

备份的价值不在"做了"，而在"能恢复"。很多团队把 dump 脚本挂上就再没验证过，直到真出事才发现某段日志缺失或 load 报错。建议每月至少做一次恢复演练，把"全量 + 日志 + online + 校验"整条链跑通，并把演练结果留档。这样灾备才真正可信。