达梦数据库远程备份
使用场景
一般部署在专门的存储节点，和普通实例一样，也可对外提供数据库服务，启动服务时添加启动参数AUXILIARY_MODE=1说明该库作为辅助实例启动。目前仅支持辅助实例是普通的单机数据库
在日常运维中，若生产数据库发生误操作（如误删数据），传统恢复方式需在本地初始化新实例并还原备份，可能因资源紧张影响生产系统稳定性。
为提升恢复效率与安全性，我们采用 达梦数据库的“辅助实例”机制，将另一台服务器配置为专用备份存储节点
我认为的好处如下：
1.直接远程备份：源库通过 DEVICE TYPE remote 将备份集写入存储节点；
2.快速恢复验证：在辅助实例上直接还原备份，用于数据比对或应急接管；
3.避免生产干扰：无需在源服务器占用额外磁盘或内存资源。
设计 为了方便区分，我将用一台windows服务器和一台linux服务器
源端 windows dm8 生产数据库
目标端 linux dm8 备份存储 + 恢复验证
首先查询目标端默认备份路径
[dmdba@dca dmbak]$ cat /dmdata/data/DAMENG/dm.ini |grep -i bak_path
CTL_BAK_PATH = /dmdata/data/DAMENG/ctl_bak #dm.ctl backup path
BAK_PATH = /dmdata/data/DAMENG/bak #backup file path
[dmdba@dca dmbak]$
现在我们需要从windows备份远程备份到linux服务器上，等同于将这台linux服务器作为备份存储，直接远程备份在linux服务器上，无需在windows服务器上备份再传输过去。
首先我先讲述一下我备份中遇到的问题
这个报错原因是因为linux服务器没有加参数AUXILIARY_MODE=1启动数据库，该参数用户辅助实例，就好比专门的存储节点，和普通实例一样，也可对外提供数据库服务。
因此我们linux端需要重启一下数据库加上参数
/home/dmdba/dmdbms/bin/dmserver /dmdata/data/DAMENG/dm.ini AUXILIARY_MODE=1
Windows端数据库再执行
BACKUP DATABASE BACKUPSET 'dmbak_20251124' DEVICE TYPE remote
parms 'USER=SYSDBA;PASSWORD=Huangshixin123**; SVC_NAME=192.168.132.220:5236';
现在我们去linux端查看备份出来的文件
已经产生了dmbak_20251124这个文件，这下有同学会问，新产生的备份文件到底是windows的备份还是linux的备份怎么区分呢，很简单小黄来告诉你
我们进入dmrman来看
show backupset '/dmdata/data/DAMENG/bak/dmbak_20251124';
RMAN> show backupset '/dmdata/data/DAMENG/bak/dmbak_20251124';
show backupset '/dmdata/data/DAMENG/bak/dmbak_20251124';
<backupset [DEVICE TYPE:REMOTE, BACKUP_PATH: /dmdata/data/DAMENG/bak/dmbak_20251124] info start ..........>
<DB INFO>
system path: D:\dm8\dmdbs\data\DAMENG
pmnt_magic: 304417394
src_db_magic: 1408140384
db_magic: 1408140384
dsc node: 1
sys mode: 0
page check: 3
rlog encrypt: 0
rlog encrypt id: 0
external cipher[id/name]: 0/
external hash[id/name]: 0/
length in char: 0
use new hash: 1
page size: 32KB
extent size: 32
case sensitive: 1
log page size: 512B
unicode_flag/charset: 1
data version: 0x7000D
sys version: V8
pseg version: 0x7000B
enable policy: 0
archive flag: 1
blank_pad_mode: 0
crc_check: TRUE
page_enc_slice_size: 4096
char_fix_storage: 0
sql_log_forbid: 0
secur_flag: 2
db_enc_extend_size: 0
page_check_hash_size: 0
dpc_magic: 0
<META INFO>
backupset sig: BA
backupset version: 0x400A
backupset sub-version: 0xE
database name: DAMENG
backup name: DB_FULL_20251124_161005_257000
backupset description:
n_magic: 0x4144620A
bakset_magic: 1095000586
parent n_magic: 0xFFFFFFFF
bakset_seqno: 0
meta file size : 124416
compressed level: 0
encrypt type: 0
parallel num: 1
backup range: database
mpp_timestamp: 1763971805
with_huge: TRUE
backupset_type: NORMAL
mpp_flag: FALSE
backup level: online
backup type: full
without log: FALSE
without mirror: FALSE
use_bct: FALSE
end_lsn: 79623
max_trxid: 224661
base begin_lsn: -1
base end_lsn: -1
base n_magic: 0xFFFFFFFF
from lsn: 0
base name:
base backupset:
backup time: 2025-11-24 16:10:11
min exec ver: 0x08010227
min dct ver: 4
pkg size: 0x04000000
bak_magic: 0
l_term_id: 0
term_id: 0
c_seqno: 7207
c_lsn: 79623
h_seqno: 7207
h_lsn: 79623
<EP INFO>
EP[0]:
begin_pkg_seq: 7194
begin_lsn: 79557
end_pkg_seq: 7207
end_lsn: 79623
<FILE INFO>
backupset directory: /dmdata/data/DAMENG/bak/dmbak_20251124
backupset name: dmbak_20251124
backup data file num: 6
backup piece num: 2
backup huge file num: 0
backup image copy file num: 0
<backup_piece_list>
$file_seq |$size(KB) |$pos_desc |$content_type
0 |46185 |dmbak_20251124.bak |DATA
1 |61 |dmbak_20251124_1.bak |LOG
<data_file_list>
$file_seq |$group_id |$group_name |$file_id |$file_path |$mirror_path |$file_len |$copy_num |$size_flag|$asm_mirror|$asm_striping
1 |0 |SYSTEM |0 |D:\dm8\dmdbs\data\DAMENG\SYSTEM.DBF| |289406976 |0 |0 |1 |0
2 |1 |ROLL |0 |D:\dm8\dmdbs\data\DAMENG\ROLL.DBF| |201326592 |0 |0 |1 |0
3 |4 |MAIN |0 |D:\dm8\dmdbs\data\DAMENG\MAIN.DBF| |201326592 |0 |0 |1 |0
4 |5 |BOOKSHOP |0 |D:\dm8\dmdbs\data\DAMENG\BOOKSHOP.DBF| |157286400 |0 |0 |1 |0
5 |6 |DMHR |0 |D:\dm8\dmdbs\data\DMHR.DBF | |134217728 |0 |0 |1 |0
<arch_file_list>
$file_seq |$dsc_seq |$file_path |$file_len |$begin_seqno |$begin_lsn |$end_seqno |$end_lsn
6 |0 | |57344 |7194 |79557 |7207 |79623
<huge_file_list>
$group_id |$schema_id|$table_id |$column_id|$file_id |$file_len |$path
<img_copy_file_list>
$dst_file_path |$src_file_path |$file_type|$file_len
<TABLESPACE INFO>
<tablespace_list>
$ts_id |$name |$state |$cache |$copy_num |$size_flag|$cipher_name |$opt_node
0 |SYSTEM |0 | |0 |0 | |65535
1 |ROLL |0 | |0 |0 | |65535
4 |MAIN |0 | |0 |0 | |65535
5 |BOOKSHOP |0 | |0 |0 | |65535
6 |DMHR |0 | |0 |0 | |65535
<backupset [DEVICE TYPE:REMOTE, BACKUP_PATH: /dmdata/data/DAMENG/bak/dmbak_20251124] info end .>
show backupsets successfully.
time used: 35.134(ms)
RMAN>
我们可以看标红的这几处，很容易看出来这个是备份的windows数据库，然后存储在linux服务器上
我觉得这个方式的好处是，首先可以作为一个找误删数据的单实例，因为每个实例误删了都可以远程备份过去，然后恢复在这个实例上，就不需要额外在生产机器上再初始化一个实例再去恢复，怕因为内存原因造成生产数据库宕机
现在我们来恢复一下这个数据库吧，为了方便区分我放以下截图
Windows端模式
Linux端
现在我们去把windows的备份恢复到linux，首先需要把linux端数据库服务停了
RESTORE DATABASE '/dmdata/data/DAMENG/dm.ini' FROM BACKUPSET '/dmdata/data/DAMENG/bak/dmbak_20251124'
recover DATABASE '/dmdata/data/DAMENG/dm.ini' FROM BACKUPSET '/dmdata/data/DAMENG/bak/dmbak_20251124'
recover database '/dmdata/data/DAMENG/dm.ini' update db_magic ;
非常好小黄启动的时候又遇到问题了
报错数据库版本不一致，小黄一看差了半年的版本，然后又得去找linux相同版本来做这个恢复
我重新上传了一个同版本linux的软件包,重新初始化一个端口不同的实例
/home/dmdba/dmdbms1/bin/dminit PATH=/dmdata/data PAGE_SIZE=16 EXTENT_SIZE=32 DB_NAME=EXAMDB CHARSET=0 INSTANCE_NAME=EXAMSVR PORT_NUM=5238 LOG_SIZE=256 SYSDBA_PWD=Dameng123 SYSAUDITOR_PWD=Dameng123
还原成功
总结
场景 | 优势 |
|---|---|
误删数据恢复 | 快速在辅助实例还原，验证数据正确性后再决定是否回切 |
多系统统一备份中心 | 多个生产库（Windows/Linux）均可远程备份至同一辅助节点 |
审计与取证 | 保留历史备份快照，用于安全事件回溯 |
测试环境初始化 | 直接从生产备份恢复到测试库，保证数据一致性 |
