干了快十年的数据库运维我自认为最不敢托大的两件事一件是删数据另一件就是数据备份。尤其是这两年手底下的库里跑着越来越多的业务前阵子帮一个兄弟单位救场他们的生产库刚好在升级前一周磁盘阵列出问题结果发现半年前的全量备份根本没留异地增量备份也因为归档没开全成了废纸——那一整晚的抢救过程基本就是我这些年反复念叨的“数据备份不是选择题是保命题”的现实版。今天就把我长期在用的这一整套达梦数据备份方案全部摊开讲从原理到命令、从脚本到恢复演练连踩过的坑一起打包看完你就可以直接抄作业。如果你也是 DBA、运维或者管着几台数据库服务器的开发这篇尤其适合你。我会围绕“数据备份”这件事讲透为什么很多人做了备份却仍然丢数据达梦数据库有哪些靠谱的备份手段以及一套能自动跑、能定时清、能验证恢复的完整方案长什么样。1. 为什么我要把“数据库备份”当成一件大事来聊1.1 备份不是工具问题是流程问题很多朋友一提到数据备份第一反应是装个软件、跑个命令、导出个文件。说实话工具层面真没什么高深的难的是把一个备份动作变成一套能持续运转、出了问题还能救命的流程。我见过太多这种情况备份命令每天都在执行日志也显示成功结果真要恢复的时候要么文件只有半截要么备份集打不开要么恢复出来的库起不了服务。原因往往很统一——从头到尾只做了“备份动作”没做“备份验证”。打个比方数据备份就像给房子装灭火器光把灭火器挂墙上不算完你得定期检查压力表、偶尔真的喷一喷真着火的时候才能指望它。这也是我为什么特别推崇 3-2-1 原则至少 3 份副本、2 种不同介质、1 份放在异地。别嫌冗余数据这东西冗余不是浪费是无常世界里唯一的确定性。我见过把全量和增量放在同一块盘上的也见过备份目录就在数据盘旁边的最后盘挂了备份一起陪葬这种案例在故障复盘里一抓一大把。1.2 数据备份的三种边界全量、增量、归档理解备份之前先分清三个概念全量备份、增量备份、归档日志。很多新手在这里混淆导致策略设计得乱七八糟。全量备份就是把整个数据库的所有数据文件、控制信息完整地复制一份它是恢复的基础底盘。增量备份则是基于上一次全量或增量备份只保存从那个时间点之后发生变化的数据块目的是缩短备份窗口、减少存储占用。归档日志就更关键了它是数据库运行过程中产生的所有重做日志的持久化副本相当于数据库的“连续录像”。只有把归档打开增量备份才有意义也才能做到按时间点恢复。我建议的策略很朴素每周一次全量每天一次增量归档始终打开备份文件按保留周期滚动清理。这套组合既能控制存储成本又能把数据丢失的窗口压缩到一天以内对绝大多数业务已经足够。1.3 备份做完离“能恢复”还差十万里这是我最想敲打各位的一点。备份的成败从来不取决于“备份命令有没有执行成功”而取决于“恢复时能不能用”。很多团队把备份当作一项日常工作交差指标只看有无备份文件这其实是自己骗自己。正确做法是定期做恢复演练。不用兴师动众找一台测试机把最近的备份集拉过去完整走一遍还原流程启动数据库跑几条业务 SQL 验证数据落位。我后面会专门用一整个章节讲演练怎么落地。你只要记住一句话每一次没有演练过的备份都有概率是一场虚假的安全感。2. 达梦数据备份的四种姿势脾气各不相同达梦数据库作为企业级关系型数据库备份手段其实相当齐全。我用下来最常用的有四种disql 联机备份、dmrman 离线备份、dexp/dimp 逻辑备份以及必须提前铺垫的归档模式。搞清楚它们的脾气和适用场景比背命令本身重要得多。2.1 disql 联机备份白天也能做的全量和增量disql 是达梦自带的命令行工具相当于 Oracle 的 sqlplus。数据库运行状态下可以直接用 SQL 命令完成备份这就是联机备份业务不停备份照做对大多数 OLTP 系统来说非常友好。最基本的全量备份命令长这样BACKUP DATABASE FULL BACKUPSET /dmbackup/full_20250101;增量备份也不复杂BACKUP DATABASE INCREMENTAL BACKUPSET /dmbackup/inc_20250102;执行完之后/dmbackup下会生成对应的备份集目录里面包含了数据文件镜像和控制信息。这个命令需要在 DBA 权限下执行建议通过专门的备份账号跑别把 sysdba 的明文口令写在脚本里到处扔。命令里的路径和备份集名字你可以随便定但一定提前规划好目录结构后面自动化脚本会依赖它。用 disql 联机备份的优点是没有停机时间缺点是如果数据库本身已经处于崩溃状态连 disql 都进不去那就只能靠下一位选手出场。2.2 dmrman 离线备份数据库起不来时的保命牌dmrman 是达梦的离线备份还原工具类比 Oracle RMAN。它的核心价值在于哪怕数据库实例已经起不来、数据文件受损你依然能用它完成备份和恢复。离线备份的基本调用方式是dmrman CTLSTMTBACKUP DATABASE /dm/data/DAMENG/dm.ini FULL BACKUPSET /dmbackup/rman_full_20250101注意这里指定的是数据库的dm.ini路径dmrman 会根据这个文件定位整个实例的数据目录。恢复时思路也很清晰先 RESTORE 再 RECOVERRESTORE 把备份集还原成数据文件RECOVER 把归档日志和增量备份追加上去让数据库恢复到某个一致的时间点。具体子句在不同 DM 小版本间略有差异执行前用dmrman help或者对照官方手册确认即可。我的个人习惯是把每周的物理备份至少留一份给 dmrman 场景使用。因为当你真的遇到崩溃级故障时disql 可能连不进去dexp/dimp 这类逻辑导出更是无从谈起dmrman 往往是最后一道防线。2.3 dexp/dimp 逻辑备份搬迁和单表救援的轻骑兵如果说物理备份是“连库带文件一起拍平”逻辑备份就是“把表和数据导成文本逻辑”。达梦提供了 dexp 导出和 dimp 导入工具类似 Oracle 的 exp/imp操作对象可以是整个库、指定模式或者某几张表。常用导出命令dexp SYSDBA/SYSDBA DIRECTORY/dmbackup FILEexp_20250101.dmp LOGexp.log恢复导入dimp SYSDBA/SYSDBA DIRECTORY/dmbackup FILEexp_20250101.dmp FULLY逻辑备份最大的好处是灵活只导一张表、跨环境迁移、把一个生产库的表搬到测试环境做开发都非常顺手。但它替代不了物理备份因为逻辑导出的效率远低于物理文件复制大数据量场景下耗时惊人而且它无法备份事务日志、无法实现增量恢复。在我心里它是“精确制导武器”物理备份才是“战略核潜艇”两者搭配才完整。2.4 归档模式所有时间点恢复的地基很多人把前面几种备份工具玩得很溜却忘了最基础的一步开启归档模式。没有归档增量备份做不了崩溃后的恢复也只能恢复到最近一次全量备份的位置中间产生的业务改动全部丢失。达梦开启归档的方式比较直观核心就是两条命令ALTER DATABASE ADD ARCHIVELOG DEST/dmarch; ALTER DATABASE ARCHIVELOG;第一条指定归档日志存放目录第二条把数据库切到归档模式。生产环境里我一般把归档目录放在独立磁盘避免数据目录和归档目录互相挤占空间。同时还要小心一个常见问题归档目录写满之后数据库会直接挂起或者拒绝写入新事务这种事故我见得太多了所以监控归档目录的使用率和使用监控磁盘空间同等重要。3. 一套能直接抄作业的自动化备份脚本前面铺垫了那么多原理现在进入最实用的环节怎么把备份自动化。手工敲命令确实也能完成备份但人不是用来重复劳动的你半夜不可能爬起来执行任务。我的做法是写一个带日志、带保留周期、带告警接口的 shell 脚本再用 crontab 调度全自动运转。3.1 设计思路备份、留证、盯告警这个脚本的设计目标有三个第一能区分全量和增量第二每次执行都写日志方便事后追溯第三备份失败时能往外抛信号方便对接企业微信、钉钉或者短信告警。我不想把脚本做得花里胡哨因为备份场景最怕“炫技”。能用 shell 五分钟讲清楚的事情就不要上复杂框架。下面这个脚本我用了很久很原生态但每一行都有用。3.2 核心脚本拆解#!/bin/bash # dm_backup.sh 达梦数据库自动备份脚本 BACKUP_BASE/dmbackup DATE$(date %Y%m%d_%H%M%S) LOG_DIR$BACKUP_BASE/logs KEEP_DAYS14 mkdir -p $LOG_DIR if [ $1 inc ]; then BAK_TYPEINCREMENTAL BAK_TAGinc_$DATE else BAK_TYPEFULL BAK_TAGfull_$DATE fi LOG_FILE$LOG_DIR/backup_$DATE.log echo [$(date %F %T)] start $BAK_TYPE backup $LOG_FILE $DM_HOME/bin/disql SYSDBA/SYSDBAlocalhost:5236 EOF $LOG_FILE 21 BACKUP DATABASE $BAK_TYPE BACKUPSET $BACKUP_BASE/$BAK_TAG; EXIT; EOF if [ $? -eq 0 ]; then echo [$(date %F %T)] backup success: $BACKUP_BASE/$BAK_TAG $LOG_FILE find $BACKUP_BASE -maxdepth 1 -name full_* -mtime $KEEP_DAYS -exec rm -rf {} \; find $BACKUP_BASE -maxdepth 1 -name inc_* -mtime $KEEP_DAYS -exec rm -rf {} \; else echo [$(date %F %T)] backup FAILED, check log! $LOG_FILE # 在这里接入你的告警脚本比如 curl 你的内部告警接口 # curl -f http://alert.内部地址/dmbackup?statusfailed exit 1 fi几个细节我说一下第一脚本里我直接用$DM_HOME/bin/disql调命令环境变量需要提前定义或者写死绝对路径。第二密码部分为了演示我直接写了 SYSDBA/SYSDBA生产环境千万别这么干建议把口令放到环境变量或者使用达梦的凭据管理能力脚本里只引用变量名。第三find清理策略只保留 14 天这个天数你自己根据存储容量、业务留存要求定但一定要有否则备份会把磁盘堆满。3.3 定时任务与保留策略脚本写好后上 crontab。我需要规划一套节奏增量太频繁会占存储太稀疏会扩大数据丢失窗口。我推荐周日全量、周一至周六增量的排班# 每周日凌晨 2:00 全量备份 0 2 * * 0 /home/dba/dm_backup.sh full /dev/null 21 # 周一至周六凌晨 2:00 增量备份 0 2 * * 1-6 /home/dba/dm_backup.sh inc /dev/null 21选凌晨两点是因为大多数业务在这个时间点的写入量最低备份任务对业务的影响最小。如果你有明确的业务低谷期按实际调整即可。另外我强烈建议把 crontab 执行用户的 shell 环境脚本比如~/.bash_profile也加载进来否则定时任务里可能找不到$DM_HOME导致备份失败这类问题非常隐蔽。3.4 命名规范与目录规划一个月后你能看懂备份吗备份文件最怕乱。全量和增量混在一起、日期缺失、目录层级不定这会让一个月的后续排查变成噩梦。我的目录规划如下/dmbackup ├── full_20250105_020001 # 每周全量 ├── full_20250112_020001 ├── inc_20250106_020001 # 每天增量 ├── inc_20250107_020001 └── logs/ # 备份日志集中存放命名规则统一为“备份类型_日期_时间”。这样做的好处一目了然找某个时间点的备份直接按目录名筛选清理过期备份直接按mtime脚本处理。日志文件单独放一个logs子目录避免和备份集混在一起影响find清理规则的准确性。4. 恢复演练把“能备份”变成“能交付”方案再好脚本跑得再欢没有经历过一次真正的恢复演练我心里始终不踏实。下面这套演练方法不挑环境、成本很低但能实打实检验备份质量。4.1 先搭一个最小折腾的演练环境不需要单独申请一台重磅配置的服务器一台虚拟机、一块闲置磁盘就够了。把目标环境初始化好确保能连到备份存储或者本地备份目录然后启动达梦实例带到 mount 或者直接停机状态为后面的 RESTORE 做准备。演练频率我建议一个月至少一次。每次演练前把当天的备份集文件大小记录下来恢复完成后再对比数据量两者能对上说明这次备份是可用的。别小看这个动作它能帮你捕获至少三类问题备份文件损坏、备份集内容不完整、恢复步骤依赖的归档日志缺失。4.2 完整恢复路径与两个高频报错假设现在要恢复到昨天凌晨的增量备份点完整路径是先用最近的全量备份集执行 RESTORE再用期间的增量备份集继续恢复中间缺失的部分由归档日志补齐。dmrman 状态下典型的恢复流程是dmrman CTLSTMTRESTORE DATABASE /dm/data/DAMENG/dm.ini FROM BACKUPSET /dmbackup/full_20250105_020001 dmrman CTLSTMTRECOVER DATABASE /dm/data/DAMENG/dm.ini FROM BACKUPSET /dmbackup/inc_20250106_020001演练中我踩到过的两个高频报错第一个是backupset path not found多半是路径写错或者权限不对。备份目录务必让运行数据库的操作系统用户有读权限不然 dmrman 根本打不开文件。第二个是恢复过程中提示归档日志断档。最常见的原因是归档目录被清理或者手动移动过文件导致从全量备份时间点到增量备份时间点之间的日志链不完整。遇到这种报错先检查归档目录的完整性和连续性确认所有日志都在再重新执行 RECOVER。这个问题的教训是清理备份和归档的时候别只靠手删一定要遵循保留策略给日志留出足够的追溯窗口。4.3 验证恢复结果的三个指标恢复命令执行完不代表数据就一定能用。我会用三个指标验证数据库实例能否正常启动并稳定运行不会中途崩溃或抛内部错误关键业务表的数据行数是否与源库一致尤其近几天有增量的表应用连接的冒烟测试让业务系统跑几个核心查询接口确认不是“空库能起带数据就挂”。这三个指标验证完后我会把演练结果连同备份集清单、恢复耗时、报错截图一起整理成一条记录存档。这既是给管理层的安全答卷也是下一次演练的对照基线。5. 长期稳定运行要提前填平的坑自动化方案落地之后真正消耗精力的反而是那些看起来不起眼的小坑。我把这些年踩过的坑集中列一下每一条都是真金白银换来的教训。5.1 磁盘空间被备份撑爆最经典的问题备份目录空间估算失误跑着跑着把磁盘吃满数据库自己先挂了。尤其是初次部署时全量备份都正常等增量积累到一定量级突然某天磁盘告警。我的经验是给备份目录单独划分磁盘容量按照“全量大小 × 保留份数 增量大小 × 每日份数”再留出 20% 余量来规划。同时给磁盘空间加监控阈值比如使用率超过 80% 就告警超过 90% 立刻人工介入。5.2 备份日志没人看等于没备份很多团队把 crontab 配上就不管了备份成功了还是失败了没人知道等到真正要恢复那天才去看日志黄花菜都凉了。我会坚持做两件事第一日志按日期归档保留方便回溯第二脚本失败时一定要有主动通知别指望人每天去翻日志。哪怕只是脚本里加一行 curl 打到内部监控系统也比被动等待强一百倍。5.3 账号权限与密码轮转备份脚本里不可能不涉及数据库口令但口令不会一成不变。企业安全制度要求定期改密一旦改了数据库密码备份脚本就会立刻失败。我建议在脚本里统一引用环境变量改密时只更新环境变量一个位置同时把备份账号的最小权限固定下来比如只要具备执行备份相关命令的权限即可不要直接拿最高权限账号跑日常任务降低误操作和泄露的风险。5.4 一张可以直接贴机房的备份自检清单我把日常巡检浓缩成一张表谁值班谁检查十分钟搞定检查项频率期望结果备份任务是否成功每日当日日志无 FAILED归档日志目录使用率每日低于 80%备份磁盘剩余空间每日足够容纳下两次备份备份集文件完整性每周随机抽查一个备份集可正常识别异地副本是否能访问每周网络和权限连通性正常本月恢复演练记录每月有完整记录且验证通过这张表我建议直接打印出来贴在机房里或者挂在团队监控看板上。别嫌简单越是简单到能长期坚持的检查越比花哨的自动化更能救命。做了这么多年的数据备份我最深的体会是备份不该被当成一个“机房动作”它应该被当成一个“产品”来打磨——可观测、可恢复、可验证。可观测是你能看到每一次备份和告警可恢复是你能拍胸脯说哪天出事都能拉回来可验证是你真的定期演练而不是嘴上说说。最后再分享一个小技巧每月做恢复演练的时候把最近的备份集切成两份一份在本地测试机恢复一份拷贝到异地环境再恢复一次这样你同时验证了备份本身的可用性和异地副本的可用性。数据备份这条路没有终点每次多填一个坑下次灾难来临的时候就多一分淡定。