接手第一套达梦数据库之前我一直习惯拿Oracle那套经验往上套RMAN脚本、归档日志清理、闪回恢复。真正跑到生产环境上一操作才发现达梦Dameng的备份工具链确实有Oracle的影子但命令写法、模式切换逻辑、工具调用方式差异相当大按惯性操作极易翻车。这套备份运维命令手册是我实际梳理达梦数据库备份方案时逐条验证过的内容覆盖逻辑备份dexp/dimp、物理备份dmrman、联机/脱机两种备份模式、定时脚本和恢复流程也把锁超时、归档目录打满这类运维现场问题一并写了进去适合刚接手达梦运维、或者准备给现有环境补备份方案的人直接参考。1. 达梦备份体系全景先搞清楚你面对的是哪种备份场景1.1 达梦的备份工具家族disql、dmrman、dexp/dimp与图形工具达梦数据库的命令行工具链比很多人想象中要完整。日常运维最常用的有四个disql达梦自带的交互式SQL工具功能和Oracle的sqlplus类似既可以执行普通SQL也可以执行备份恢复语句、查看动态性能视图。它是最常打交道的入口。dmrman达梦的备份恢复管理工具专门负责物理备份、增量备份、恢复和校验。它是脱机备份恢复场景下的主力命令组织形式和Oracle RMAN有几分相似但参数差异很大。dexp / dimp逻辑导出、导入工具对应Oracle的exp/expdp和imp/impdp。适合做表级、用户级的数据搬迁和备份粒度比物理备份细得多。Manager / DTS图形化管理工具以及用于数据迁移的DTS工具。图形工具适合人手操作的场景但生产环境自动化和定时任务必须依赖命令行这也是本手册全部采用命令方式的原因。还有一个容易被忽略的点达梦的图形工具并不是所有服务器环境都会安装全。很多生产服务器为了精简和安全考虑只装了数据库服务端和命令行工具。因此运维人员必须熟练掌握disql和dmrman这两套命令否则真到出故障的时候连备份恢复都没法执行。1.2 逻辑备份与物理备份的本质区别理解达梦备份的第一步是先分清逻辑备份和物理备份这两个完全不同的世界。逻辑备份导出的是数据和对象定义本身比如表结构、索引定义、存储过程、数据记录最终生成一个包含SQL和数据的文件。dexp生成的dmp文件就是典型代表。它的优势是粒度灵活可以选择某个用户、某张表、某个模式恢复时可以直接导入到另一套环境中跨版本、跨机器迁移都能用。劣势是速度相对慢大批量数据导出导入时对系统资源有占用而且全量恢复时要逐个对象重建恢复时间偏长。物理备份则是直接复制数据库底层的物理文件和数据页备份内容包含数据文件、控制信息、日志信息等。dmrman生成的备份集是典型代表。它的优势是速度快、恢复效率高、能够支持基于时间点的恢复劣势是通常依赖归档日志而且恢复时目标环境的版本、路径、数据库名等信息匹配要求更严格。用一个生活化类比来说逻辑备份像是把整座仓库的货品清点一遍登记成一份详细的货物清单物理备份则像是直接把仓库连同货架打包搬走。前者灵活后者完整且快。实际生产环境中两者通常会结合使用——日常高频做逻辑备份重要时间节点做物理全备形成多重保险。1.3 不同场景下的备份选型对照在达梦数据库上做备份方案设计时我会按业务场景先做一轮选型判断。以下这个对照表是我在实际项目中反复使用的一个判断依据场景推荐备份方式工具原因单表误删、某用户数据被误更新逻辑备份dexp/dimp粒度细单表恢复最快整库周期性备份、容灾恢复物理备份dmrman或disql备份语句速度快恢复完整跨平台/跨版本迁移数据逻辑备份dexp/dimp或DTS结构重构灵活生产库重大变更前快照物理备份联机disql中执行备份不中断业务可回滚每天定时低成本备份逻辑备份dexp crontab对系统影响小完整故障恢复场景物理全备增量备归档dmrman恢复链完整这个选型逻辑的核心是先看恢复目标再定备份方式。备份永远是为了恢复服务的不是备份得越多越好。搞清楚每类备份对应的恢复场景才不至于在关键时刻选错工具。2. dexp/dimp逻辑备份最常用也最容易忽视细节的命令组2.1 dexp导出命令的参数拆解与示例dexp是达梦的逻辑导出工具命令调用方式比较直接。最基础的连接格式是dexp USERIDSYSDBA/SYSDBAlocalhost:5236 FILE/dm/backup/full_20250101.dmp LOGexp_full.log这里的USERID包含用户名、密码、IP和端口文件路径通过FILE指定日志通过LOG指定。如果没有指定路径文件会生成在当前用户目录下这点在生产环境容易造成困扰建议每次都写绝对路径。实际运维中我更常用的几个导出场景如下。全库导出dexp USERIDSYSDBA/SYSDBAlocalhost:5236 FILE/dm/backup/full_20250101.dmp FULLY LOG/dm/backup/log/exp_full_20250101.log按用户导出dexp USERIDSYSDBA/SYSDBAlocalhost:5236 FILE/dm/backup/schema_order.dmp OWNERORDER_USER LOG/dm/backup/log/exp_schema_20250101.log按表导出dexp USERIDSYSDBA/SYSDBAlocalhost:5236 FILE/dm/backup/tables_t1.dmp TABLESORDER_USER.T_ORDER,ORDER_USER.T_ORDER_DETAIL LOG/dm/backup/log/exp_tables_20250101.log几个容易踩坑的参数OWNER表示按用户/模式导出TABLES表示按指定表导出两者不要混用。PARALLEL参数控制并行度但8.1之前的部分版本对并行的支持不完整使用前先执行SELECT * FROM v$version;确认版本特性。还有EXCLUDE和INCLUDE参数分别表示排除和只包含指定对象类型比如只导出存储过程、只导出表结构等场景会用到。2.2 dimp导入与建库、建用户的前置问题dimp是dexp对应的导入工具基础用法和导出对称dimp USERIDSYSDBA/SYSDBAlocalhost:5236 FILE/dm/backup/schema_order.dmp LOG/dm/backup/log/imp_schema_20250101.log SCHEMASORDER_USER但真正执行导入的时候要注意一个前置问题目标数据库的用户必须提前创建好。很多人从MySQL或Oracle迁移到达梦时经常问“达梦迁移工具迁移MySQL数据库表时需在达梦提前创建好用户是吗”——答案是需要。达梦的逻辑导入不会自动创建模式对应的用户如果导入前目标用户不存在DIMP会直接报错错误信息类似“用户不存在”或者“模式不存在”。正确做法是先在disql中手动创建用户CREATE USER ORDER_USER IDENTIFIED BY your_password; GRANT DBA TO ORDER_USER;为什么需要DBA权限因为逻辑导入不仅要导入数据还要创建表、索引、视图、存储过程等对象如果权限不足导入过程中会报大量权限相关错误。生产环境建议按最小权限分配但在导入场景下给导入账号足够的DDL权限能让整个过程顺畅很多。如果担心权限过大可以等导入完成后再回收不必要的权限。另一个常见问题是重复导入时报对象已存在。可以用TABLE_EXISTS_ACTION参数控制比如dimp USERIDSYSDBA/SYSDBAlocalhost:5236 FILE/dm/backup/schema_order.dmp TABLESORDER_USER.T_ORDER TABLE_EXISTS_ACTIONREPLACE LOGimp_replace.logTABLE_EXISTS_ACTION常用的取值有REPLACE替换、SKIP跳过、APPEND追加。这个参数一定要在导入前想清楚选错可能导致数据重复或旧数据残留尤其是在正式环境做恢复时建议先在测试实例上试跑一次。2.3 逻辑备份的字符集与并行度问题字符串集问题在逻辑备份/恢复场景里非常隐蔽。达梦的字符集在建库时就已经固化如果源库和目标库的字符集不一致导出文件里的中文可能在导入后变成乱码。检查字符集的方式是在disql中执行SELECT * FROM V$NLS_PARAMETERS;重点关注两个参数NLS_CHARACTERSET字符集和NLS_NCHAR_CHARACTERSET国家字符集。如果源库是GB18030目标库是UTF-8跨库导入时出现乱码的概率极高。稳妥的做法是在建库阶段就统一字符集或者在迁移前做字符集转换规划而不是等导入完成后再尝试补救。并行度是另一个容易被忽略的点。dexp在8.1及以上版本支持PARALLEL参数例如dexp USERIDSYSDBA/SYSDBAlocalhost:5236 FILE/dm/backup/full.dmp FULLY PARALLEL4 LOGexp_parallel.log并行参数能提升大数据量导出的速度但不要盲目调高。并行度太高会导致IO和内存压力上升在高峰期导出反而可能拖垮正常业务。我的经验是4到8之间的并行度对绝大多数服务器来说已经够用具体数值要根据CPU核数和磁盘IO能力来定建议先跑一次小数据量测试观察资源占用再逐步调高。3. dmrman物理备份从归档配置到联机备份实战3.1 开启归档模式物理备份绕不开的前置条件有Oracle经验的人都知道数据库要支持热备份、才能做基于时间点的恢复通常都得开启归档模式。达梦也一样。如果数据库没有开启归档联机物理备份的支持会受到严格限制恢复时也无法完整应用日志一旦发生故障可能只能恢复到备份时刻、后续数据全部丢失。达梦开启归档有两种方式。第一种是使用disql命令动态修改步骤如下ALTER DATABASE MOUNT; ALTER DATABASE ADD ARCHIVELOG DEST/dm/arch, TYPELOCAL, FILE_SIZE1024, SPACE_LIMIT10240; ALTER DATABASE ARCHIVELOG; ALTER DATABASE OPEN;注意这里的关键逻辑修改归档模式前数据库需要先处于MOUNT状态和Oracle的流程非常像。ADD ARCHIVELOG语句中的DEST指定归档目录FILE_SIZE表示单个归档文件的大小单位MBSPACE_LIMIT表示归档空间上限单位MB建议根据磁盘空间规划设置合理的上限不要简单设为0否则归档目录可能一直膨胀直至磁盘打满。第二种方式是直接修改配置文件dmarch.ini和dm.ini修改后重启数据库服务。dmarch.ini内容大致如下[ARCHIVE_LOCAL1] ARCH_TYPE LOCAL ARCH_DEST /dm/arch ARCH_FILE_SIZE 2048 ARCH_SPACE_LIMIT 10240然后修改dm.ini中的ARCH_INI参数为1重启数据库生效。这种方式适合批量部署和多机环境因为配置文件可以统一分发。3.2 两种入口disql联机备份与dmrman脱机备份物理备份在达梦中有两种常见的执行入口很多初学者容易混淆。第一种入口disql联机备份。数据库处于OPEN状态时直接在disql中执行备份语句即可BACKUP DATABASE FULL BACKUPSET /dm/backup/online_full_20250101;这条语句会生成一个完整备份集备份过程中数据库可以继续对外提供服务对业务影响很小。还可以按表空间备份BACKUP TABLESPACE MAIN FULL BACKUPSET /dm/backup/ts_main_full_20250101;联机备份的优点是操作简单、无需停库适合日常定期备份。但要注意联机备份依赖归档日志来保证一致性因此必须已经开启归档模式否则数据库会报错或生成的备份集无法用于完整的恢复流程。第二种入口dmrman脱机备份。这种方式的命令格式和disql截然不同需要指定数据库的dm.ini路径而不是用连接字符串dmrman RMAN BACKUP DATABASE /dm/data/DAMENG/dm.ini FULL BACKUPSET /dm/backup/offline_full_20250101;脱机备份要求在数据库处于关闭或MOUNT状态下执行。如果数据库还在运行dmrman会报“数据库正在运行”之类的错误。所以执行脱机备份前必须先把服务停下来systemctl stop DmServiceDMSERVER或者使用达梦自带的启停脚本cd /dm/dmdbms/bin ./DmServiceDMSERVER stop脱机备份的完整性和一致性是最好的因为备份时没有并发事务在写入恢复时也最干净。它的代价是必须停库适合停机窗口内执行比如每周日凌晨的维护窗口。3.3 增量备份与备份集校验增量备份是物理备份体系中节省时间和空间的关键手段。dmrman中进行增量备份的语法如下RMAN BACKUP DATABASE /dm/data/DAMENG/dm.ini INCREMENT WITH BACKUPDIR /dm/backup BACKUPSET /dm/backup/incre_20250108;这里的INCREMENT表示执行增量备份WITH BACKUPDIR用于指定查找已有备份集的目录以便dmrman判断增量基准。增量备份不能脱离全量备份独立存在恢复时需要一个基础全备加上之后的增量备依次应用才能把数据恢复到最新状态。备份集校验也是一个建议养成习惯的步骤。dmrman中可以用RMAN CHECK BACKUPSET /dm/backup/online_full_20250101;这个命令会读取备份集的元数据并检查备份文件是否完整可用。备份集文件可能包含多个文件日常用tar或cp命令移动、复制时容易漏文件校验命令能提前发现这类问题。我的习惯是每次备份完成后执行一次备份集校验每周在定时任务中自动校验一次关键备份集防止备份文件在磁盘上静默损坏。4. 定时备份脚本把备份运维从“人肉”变成“自动化”4.1 一个可直接抄的Linux定时备份脚本手工执行备份命令只能应付一次性需求真正运维场景中必须靠定时任务自动化。下面这个脚本是经过多次生产环境验证的达梦逻辑备份脚本可以直接复制后按环境修改。#!/bin/bash # 达梦数据库定时备份脚本 # 适用每日逻辑备份 每周物理全备 DATE$(date %Y%m%d_%H%M%S) BACKUP_BASE/dm/backup DM_BIN/dm/dmdbms/bin DB_HOSTlocalhost DB_PORT5236 DB_USERSYSDBA DB_PWDSYSDBA SCHEMA_NAMEORDER_USER export LD_LIBRARY_PATH$DM_BIN:$LD_LIBRARY_PATH mkdir -p $BACKUP_BASE/logic $BACKUP_BASE/physical $BACKUP_BASE/log # 每日逻辑备份按用户导出 $DM_BIN/dexp USERID$DB_USER/$DB_PWD$DB_HOST:$DB_PORT \ FILE$BACKUP_BASE/logic/${SCHEMA_NAME}_${DATE}.dmp \ LOG$BACKUP_BASE/log/exp_${DATE}.log \ OWNER$SCHEMA_NAME # 删除7天前的逻辑备份 find $BACKUP_BASE/logic -name *.dmp -mtime 7 -exec rm -f {} \; find $BACKUP_BASE/log *.log -mtime 7 -exec rm -f {} \;脚本的核心逻辑分三段定义变量、执行导出、清理过期文件。其中export LD_LIBRARY_PATH这行很关键达梦的命令行工具依赖动态库如果不设置环境变量直接执行dexp可能报找不到共享库的错误。配合crontab使用在每天凌晨执行30 2 * * * /dm/scripts/backup_dm.sh /dm/scripts/backup_dm.log 21为什么选凌晨2点30分因为大多数业务系统在这个时间点负载最低备份任务对生产影响最小。具体时间可以根据业务波峰波谷情况调整但要确保和其他定时任务错开避免多个任务同时抢IO。4.2 备份保留周期与磁盘空间管理备份做得好不好很大程度上取决于磁盘空间规划。很多事故不是因为备份失败而是因为备份把磁盘撑爆了反过来拖垮生产。这里分享一套我认为比较合理的保留周期方案备份类型频率保留周期空间预估逻辑备份每日1次7天按单次备份大小 × 7估算物理全备每周1次4周按全备大小 × 4估算物理增量每日1次7天按增量大小 × 7估算月度物理全备每月1次3-6个月计入长期归档脚本中用find加-mtime参数控制删除时间是最常见也最稳妥的方式。例如find /dm/backup/logic -name *.dmp -mtime 7 -exec rm -f {} \;这条命令删除7天前的dmp文件。-mtime 7表示文件修改时间超过7天符合条件就执行删除。建议先用-print参数打印结果确认一遍再换成-exec rm -f执行避免误删。磁盘空间监控也要纳入日常运维。达梦自带的动态视图里可以通过查询V$ARCHIVED_LOG等视图检查归档日志情况同时服务器层面要配置磁盘使用率告警建议阈值为80%达到阈值就要及时清理或扩容。否则数据库可能在写入时突然报“磁盘空间不足”严重影响业务。4.3 定时脚本最常见的失败坑定时备份脚本上线后最常见的失败原因并不是脚本本身逻辑错误而是环境变量不一致。手动执行脚本时当前Shell会话往往已经提前加载了达梦的环境变量但crontab任务默认是一个全新的Shell环境不会加载用户的.bash_profile或/etc/profile导致脚本里执行的dexp命令找不到动态库。解决办法就是脚本内部显式设置LD_LIBRARY_PATH或者将环境变量写入脚本开头而不是依赖系统登录环境。第二个常见坑是忘记创建备份目录。mkdir -p能自动创建多层目录但很多人前期调试时手动建好了目录脚本里就不写mkdir语句。一旦备份目录被清理或者数据目录迁移整个脚本就会失败。好的习惯是在脚本中始终保留mkdir -p幂等性设计让脚本更健壮。第三个坑是备份文件名冲突。如果使用date %Y%m%d作为文件名后缀每天执行一次没有问题但如果一天执行多次比如手动补跑定时任务执行同名文件会被覆盖。建议精确到时分秒或者在同一时间维度的基础上加一个进程号确保文件名唯一。5. 恢复实操从单表误删到整库重建5.1 单表误删的快速恢复路径日常运维中单表数据误删、误更新是最常见的故障类型。这类问题的恢复目标通常很明确只恢复某一张表而不是重建整个数据库。此时逻辑备份是首选方案。如果之前用dexp按表做过导出恢复非常直接dimp USERIDSYSDBA/SYSDBAlocalhost:5236 FILE/dm/backup/t_t1.dmp TABLESORDER_USER.T_ORDER TABLE_EXISTS_ACTIONREPLACE LOGimp_t1.log如果只有全库逻辑备份也可以从全量dmp文件中单表导入。dexp导出的是完整的逻辑数据流dimp导入时指定TABLES参数就会只从备份文件中筛选对应表的数据。前提是备份文件中包含这张表的数据所以表误删后不要犹豫第一时间确认最近的备份文件是否在有效保留期内。恢复前有一个重要步骤先确认表结构是否还存在。如果只是数据被清空、表结构还在用TABLE_EXISTS_ACTIONAPPEND追加数据即可如果表结构也被删除则需要先在目标库重建表结构再导入数据或者直接使用REPLACE让导入过程自动创建表并填充数据。不同情况下选择不同策略操作前要判断清楚。5.2 整库恢复的标准流程整库恢复通常发生在严重故障场景比如数据文件损坏、存储故障、实例无法启动。此时物理备份恢复是主力方案。整库恢复的标准流程如下第一步停库。systemctl stop DmServiceDMSERVER第二步进入dmrman执行恢复。dmrman RMAN RESTORE DATABASE /dm/data/DAMENG/dm.ini FROM BACKUPSET /dm/backup/online_full_20250101;RESTORE命令负责把备份集中的数据文件恢复到指定目录注意这里指定的是dm.ini的路径不是连接字符串。第三步应用归档日志将数据库恢复到最新或指定时间点。RMAN RECOVER DATABASE /dm/data/DAMENG/dm.ini UNTIL TIME 2025-01-08 12:00:00;如果不指定UNTIL TIME则应用所有可用归档日志恢复到最新状态。如果应用了增量备份集还可以先恢复增量RMAN RECOVER DATABASE /dm/data/DAMENG/dm.ini FROM BACKUPSET /dm/backup/incre_20250108;第四步更新数据库魔数。RMAN RECOVER DATABASE /dm/data/DAMENG/dm.ini UPDATE DB_MAGIC;这一步很容易被漏掉。达梦通过数据库魔数DB_MAGIC标识数据库的唯一性恢复后的数据文件与原有的控制信息不匹配如果不更新魔数启动时可能报错。执行UPDATE DB_MAGIC相当于告诉数据库“这是一次合法的恢复请更新标识”。第五步重新启动数据库验证。systemctl start DmServiceDMSERVER启动后连接数据库检查关键表的数据量、最近事务是否完整必要时对比备份时间和归档日志的应用情况。5.3 恢复演练验证备份集有效性的唯一标准在我看来备份运维最重要的一条经验是从不演练恢复的备份方案等于没有备份方案。备份文件躺在那里看似很安全但真到恢复那一刻才知道备份集是否完整、归档日志是否连续、命令步骤是否遗漏一切都晚了。建议每季度至少做一次完整的恢复演练。具体做法是在测试环境搭建一套配置相同的达梦实例把生产环境的物理全备和增量备份复制过去按整库恢复流程完整走一遍记录恢复耗时确认数据完整。逻辑备份则每月抽查一次从备份文件中随机选择一两张表做导入验证。恢复演练还能帮你发现一些平时注意不到的问题比如备份集文件在传输过程中是否损坏、目标环境的磁盘空间是否足够容纳恢复后的数据、命令里的路径和版本是否匹配等。我在一次演练中就发现生产环境的增量备份文件因为文件名中包含特殊字符导致编写恢复命令时引号处理不当备份根本应用不上。这种问题如果不是提前演练真到故障时刻根本来不及思考。6. 运维中容易让人崩溃的现场问题锁超时与备份失败6.1 锁超时定位从报错到找到阻塞会话达梦数据库在业务高峰时经常出现锁超时问题错误信息通常带有“锁超时”字样或错误码-3367。出现这类报错意味着一个会话在等待另一个会话持有的锁等待时间超过了数据库锁等待超时阈值。定位锁超时的第一步是查询当前事务和锁的状态。常用的动态视图有V$TRX、V$LOCK和V$SESSIONS。查询当前所有会话和事务信息的SQL如下SELECT S.SESS_ID, S.SQL_TEXT, S.STATE, T.ID AS TRX_ID FROM V$SESSIONS S LEFT JOIN V$TRX T ON S.TRX_ID T.ID;再看谁在阻塞谁可以通过V$LOCK找到锁等待关系SELECT L.TRX_ID, L.BLOCKED, S.SESS_ID, S.SQL_TEXT FROM V$LOCK L LEFT JOIN V$SESSIONS S ON L.TRX_ID S.TRX_ID WHERE L.BLOCKED 1;BLOCKED字段等于1的会话表示正在等待锁。找到阻塞会话后先通过SQL_TEXT判断是什么语句在阻塞通常是大事务更新大量数据却迟迟没有提交或回滚。确认无误后可以使用达梦的会话关闭存储过程终止会话SP_CLOSE_SESSION(会话ID);需要特别提醒的是杀会话前务必确认会话正在执行的事务可以合理中断。盲目杀会话可能导致事务回滚对业务的影响可能比锁超时本身更大建议先和业务方沟通确认。如果长期存在锁超时问题除了处理临时会话还要从代码层面排查事务是否及时提交、是否缺少索引导致行锁升级为表锁等根本原因。6.2 归档目录打满导致备份失败的处理归档目录打满是达梦运维里非常典型的备份失败诱因。归档日志持续写入如果没有合理上限或及时清理磁盘会在某个业务高峰被写满数据库可能直接挂起或报错。处理归档满的第一步是确认哪些归档文件可以清理。前提是这些归档已经被包含进完整的备份链中。如果保留策略是每天做物理全备那么全备之前的归档日志就可以放心清理如果依赖增量备份延长恢复链就要确保清理的归档不影响增量备份的应用。常用查询语句SELECT * FROM V$ARCHIVED_LOG ORDER BY STAMP DESC;确认安全后可以手动删除已经过期的归档文件也可以在dmarch.ini中配置归档空间上限来控制。更好的做法是配置自动清理任务比如每天凌晨备份完成后通过Linux的find命令清理一周前的归档文件find /dm/arch -name *.log -mtime 7 -exec rm -f {} \;注意归档文件的后缀和目录结构因配置而异执行前先用ls /dm/arch确认实际文件名格式。6.3 版本差异与兼容性问题排查达梦数据库有不少版本分支不同小版本之间的命令行为和参数支持有差异。比如逻辑导出工具dexp的PARALLEL参数在8.1之前的部分版本中就无法正常使用dmrman中一些恢复语句的语法也有版本演进。遇到过按教程执行却报语法错误的情况第一反应应该先确认服务器上的数据库版本和客户端工具版本。查看版本信息的命令SELECT * FROM V$VERSION;同时检查客户端工具的版本使用dexp或dmrman时带上-V参数可以查看工具版本。生产环境一定要保证disql、dexp、dimp、dmrman这些工具和服务端版本匹配否则可能在备份恢复过程中出现莫名其妙的错误。版本兼容问题一旦出现不要盲目调参数优先查阅对应版本的产品手册达梦官方手册对每个参数的版本支持范围有明确说明这也是我排查版本类问题时的首选依据。按我个人经验接手任何一套达梦数据库最先要做的不是急着写备份脚本而是在测试环境完整跑通一次从全备到增量再到恢复的流程。把每条命令的实际报错、每种方案的耗时都记录下来再固化成运维手册。没有成功验证过的恢复方案生产环境里再漂亮的备份设计都只是纸面功夫。这套命令和流程我反复用过多次按这个顺序做下来备份运维这件事不会太折磨人。
