传统Oracle备份大多落在本地磁盘或磁带上，随着企业业务逐步上云，把备份集放到云端对象存储已经成为主流做法。Azure Blob存储凭借按量计费、容量几乎无上限、支持异地冗余等特性，成为不少团队存放Oracle备份的首选目标。这篇文章从架构设计讲起，给出两种经过验证的实施方案，并把RMAN参数配置、认证处理、恢复验证等关键环节逐一展开，帮你少踩坑。
一、整体架构与认证方式的选择
Oracle本身并不直接理解Azure Blob协议，RMAN的备份目标本质上必须是操作系统层面可见的一个路径或磁带设备。因此整个方案的核心思路是：在操作系统中构造出一个指向Azure Blob的挂载点或接口，让RMAN把这个挂载点当成普通文件系统目录来写备份文件。
目前主流做法有两条路。第一条是使用Azure文件共享（Azure Files），它提供标准SMB协议接口，在Linux上通过mount -t cifs挂载，对Oracle完全透明，RMAN无需任何特殊配置。第二条是使用Blob存储本身，通过AzCopy或自定义脚本把本地备份文件再上传到Blob容器中，属于两段式方案，优点是可以利用Blob的分层存储降低长期保留成本。
认证方面，Azure推荐使用存储账户密钥或更安全的共享访问签名（SAS）。如果是长期挂载，建议为文件共享生成一个只有读写权限、有效期足够长的SAS令牌，避免直接暴露存储账户主密钥。如果Oracle运行在Azure虚拟机内，还可以配合托管标识（Managed Identity）做无密钥访问，不过这种方式主要用于REST API调用，SMB挂载场景仍然依赖密钥或SAS。
二、方案一：通过SMB挂载Azure文件共享实现RMAN直写
这种方式最简单，RMAN把挂载点当本地目录用，备份策略几乎不用改动。先在Azure门户创建存储账户，注意账户类型要选择FileStorage或标准通用账户，并启用文件共享功能。然后在Linux服务器上执行挂载操作。
# 安装cifs工具 yum install -y cifs-utils # 创建挂载点和凭据文件 mkdir -p /mnt/orabackup chmod 777 /mnt/orabackup # 写入凭据文件，权限收紧 cat > /etc/orabackup.cred << EOF username=orastorageaccount password=你的存储账户密钥或SAS EOF chmod 600 /etc/orabackup.cred # 执行挂载 mount -t cifs //orastorageaccount.file.core.windows.net/orabackup \ /mnt/orabackup -o vers=3.0,credentials=/etc/orabackup.cred,dir_mode=0777,file_mode=0777 # 验证挂载成功 df -h /mnt/orabackup echo test > /mnt/orabackup/test.txt
挂载完成后，配置RMAN把备份写到这个目录。需要注意SMB文件系统对并发写入和文件锁的处理与本地磁盘不同，建议将通道数控制在合理范围，并在RMAN中启用大文件分块。
-- 配置RMAN备份到挂载目录
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/mnt/orabackup/%d_%U.bkp';
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/mnt/orabackup/ctl_%F.bak';
-- 执行全库备份，限制单块大小避免SMB传输超时
RUN {
ALLOCATE CHANNEL c1 DEVICE TYPE DISK MAXOPENFILES 1;
BACKUP AS COMPRESSED BACKUPSET
INCREMENTAL LEVEL 0
SECTION SIZE 4G
DATABASE PLUS ARCHIVELOG DELETE INPUT;
RELEASE CHANNEL c1;
}
这里有几个参数值得说明。SECTION SIZE 4G把大文件切成4GB的分段并行处理，即使中途中断也可以断点续传级别地重试；压缩备份集能有效减少网络传输量，毕竟走的是公网或虚拟网络到存储端点的链路；单通道设计是因为SMB挂载点在多通道并发写入时可能出现锁冲突，先保证稳定再谈速度。
三、方案二：本地暂存加AzCopy推送Blob
如果对备份窗口要求严格，网络直写太慢，可以采用两段式方案：RMAN先备份到本地快速磁盘，完成后由脚本通过AzCopy异步推送到Blob容器。这种方式的好处是RMAN的执行时间不受网络带宽制约，上传失败也不影响备份本身。
#!/bin/bash # 备份并上传脚本示例 BACKUP_DIR=/u01/backup BLOB_URL="https://orastorageaccount.blob.core.windows.net/orabackup" SAS_TOKEN="?sv=2022-11-02&ss=b&srt=co&sp=rwlac&se=2026-12-31&sig=xxxx" # 第一步：RMAN本地备份 rman target / << EOF BACKUP AS COMPRESSED BACKUPSET FORMAT '$BACKUP_DIR/%d_%U.bkp' DATABASE PLUS ARCHIVELOG; EOF # 第二步：AzCopy上传，--put-md5便于完整性校验 azcopy copy "$BACKUP_DIR/*.bkp" "$BLOB_URL/$SAS_TOKEN" --recursive --put-md5 # 第三步：校验成功后清理本地文件 if [ $? -eq 0 ]; then find $BACKUP_DIR -name "*.bkp" -mtime +1 -delete fi
使用AzCopy时，建议开启--put-md5参数，上传时会计算校验和写入Blob元数据，恢复前可以比对确认文件未被网络传输损坏。AzCopy本身支持断点续传和自动并发调优，大备份文件传输效率远高于手工curl调用REST接口。
这个方案还有一个延伸玩法：利用Blob的生命周期管理策略，把超过30天的备份自动从热访问层迁移到冷存储或归档层，长期保留成本可以下降百分之七十以上。但要注意归档层的Blob解冻需要数小时，如果恢复演练可能随时发生，至少保留最近一份全备在热层。
四、恢复验证与日常运维要点
备份做得再好，没有恢复验证等于零。建议每月至少做一次完整的恢复演练，可以在Azure上临时拉起一台同版本Oracle的虚拟机，把Blob中的备份拉回本地进行restore和recover，确认备份集可用、控制文件和归档日志完整。
-- 恢复演练核心步骤 RESTORE SPFILE FROM '/restore_dir/ctl_c-1234567890-20250101-00.bak'; STARTUP FORCE NOMOUNT; RESTORE CONTROLFILE FROM '/restore_dir/ctl_c-1234567890-20250101-00.bak'; ALTER DATABASE MOUNT; CATALOG START WITH '/restore_dir' NOPROMPT; RESTORE DATABASE; RECOVER DATABASE; ALTER DATABASE OPEN RESETLOGS;
日常运维上还有几个容易忽略的点。第一，监控备份目录的空间水位，Azure文件共享有配额上限，超限后写入会直接失败，RMAN作业报错但可能已经写了半个文件；第二，SMB挂载在某些内核版本上长时间空闲后会掉线，建议在fstab中加入_netdev选项并配合autofs实现自动重连；第三，SAS令牌过期前务必轮换，否则某天凌晨的备份会静默失败，最好在监控中加入对备份文件时间戳的检查，超过24小时没有新文件就告警。
最后提醒一句，如果数据库跑在Azure虚拟机上，尽量让存储账户和VM处于同一区域，内网传输不仅快而且免流量费。跨区域容灾需求可以另开一个账户，用存储账户级别的异地冗余或对象复制来实现，比每次备份写两份要优雅得多。
Oracle备份Azure Blob存储RMAN备份修改时间：2026-09-07 09:22:43