@TOC

前言

最近好久没更新 Oracle 相关内容了，都在搞备份的东西，为啥呢？

因为最近 Oracle 相关的内容都是很基础的，也没有遇到什么问题，所以就自然没什么内容可写了，反倒是最近几天都在研究 TiDB 备份，顺便学习了下 TiDB 的体系结构以及各种组件，也是比较有收获的。

话说回来，书接上篇使用 BR 备份 TiDB 到 AWS S3 存储备份到 AWS S3，部署完之后发现快照备份执行到一半还是会失败，分析后说原因可能是 AWS 公网络延迟导致的，到最后也没解决。

所以又换了阿里云 OSS 测了一下，今天也记录一下测试过程中遇到的一些问题，虽说最后也没成功。

阿里云 OSS

在阿里云上创建 OSS 存储部分不是我操作的，所以没有记录，我这边是直接获取到了 OSS 存储的 Bucket、AK/SK 信息以及 Endpoint，有这些信息就可以了。

为了验证是否可以正常连接阿里云 OSS 存储，可以下载 oss-browser 或者 S3 Browser，输入上面获取到的信息就可以连接到阿里云 OSS 存储：

如果使用 S3 Browser 记得要选择 Virtual hosted style：

阿里云 OSS 不支持 Path style，会报错：

连接后可以看到创建好的 OSS 存储以及里面的内容，测试可以正常上传文件：

至此，阿里云 OSS 存储验证正常。

日志备份

日志备份是一个 task，所以只需要启动一次即可：

[root@tidb ~]# cat<<-EOF>/root/scripts/brbackuplog.sh
AccessKey="根据实际情况填写"
SecretKey="根据实际情况填写"
Bucket="根据实际情况填写"
Endpoint="根据实际情况填写"
PDIP="根据实际情况填写"
export AWS_ACCESS_KEY_ID=$AccessKey
export AWS_SECRET_ACCESS_KEY=$SecretKey
CURDATE=$(date +%Y%m%d%H%M%S)
br log start --task-name=pitr \
--pd "${PDIP}" \
--storage "s3://${Bucket}/backup-data/log-backup" \
--s3.endpoint="https://${Endpoint}" \
--s3.provider="alibaba" \
--log-file brbackuplog-$CURDATE.log

echo s3://${Bucket}/backup-data/log-backup
EOF

启动日志备份任务：

1 2	[root@tidb ~]# chmod +x /root/scripts/brbackuplog.sh [root@tidb ~]# sh /root/scripts/brbackuplog.sh

很不幸，执行报错了：

1	Error: Alibaba RAM Provider Retrieve: Get "http://100.100.100.200/latest/meta-data/ram/security-credentials/": dial tcp 100.100.100.200:80: i/o timeout

这个问题分析了很久，后来在 TiDB 社区上搜到了这个问题，是个 BUG，可以参考以下问答：

https://asktug.com/t/topic/1029983

是因为在 provider 是 alibaba 的情况下，没有使用到环境变量中 AK/SK 的问题导致的这个报错，但是在 BR v7.5.3 版本已经进行修复：

所以只需要将 BR 升级到 v7.5.3 以上版本即可避免这个问题，我这里选择小版本用最新的 v7.5.7 版本：

[root@tidb ~]# wget https://tiup-mirrors.pingcap.com/br-v7.5.7-linux-amd64.tar.gz
[root@tidb ~]# tar -xf br-v7.5.7-linux-amd64.tar.gz -C /usr/sbin/
[root@tidb ~]# br --version
Release Version: v7.5.7

这里提一嘴：因为我 TiDB 集群 v7.5.0 版本的限制，所以选择了跟 TiDB 集群版本相同的 BR 版本，其实这是个思维误区，其实应该选择小版本最新，避免这些已经被修复的 BUG。

这个问题解决了，重新执行日志备份任务，又报错了：

1
2

Error: RequestError: send request failed
caused by: Head "https://*******.oss-cn-shanghai.aliyuncs.com/backup-data/log-backup/backup.lock": read tcp xxxxx:38072->106.14.228.174:443: read: connection reset by peer

这个看起来还是网络问题，但是 telnet 端口又是通的：

[root@tidb ~]# telnet 106.14.228.174 443
Trying 106.14.228.174...
Connected to 106.14.228.174.
Escape character is '^]'.

后来在 TiDB 社区提了个问题，跟社区朋友们讨论了一下，有了一些头绪，怀疑不是 BR 工具本身的问题，有可能是这台 Linux 主机本身就不能访问 OSS，使用 ossutil64 测了一下能不能直接连接 OSS 存储：

1
2

[root@tidb ~]# ossutil64 ls oss://csi-tidb-backup/
Error: Get http://csi-tidb-backup.oss-cn-shanghai.aliyuncs.com/?delimiter&encoding-type=url&marker&max-keys=1000&prefix: read tcp 10.207.38.40:37130->106.14.228.174:80: read: connection reset by peer, Bucket=csi-tidb-backup, Object=

可以看到跟上面的报错一致，网络也通，端口也通，为什么不能访问？咨询了一下阿里云那边，检查了 OSS 那边的日志，发现有一个报错：

提示没有权限，后来发现是因为阿里云 RAM 的用户没有 OSS 权限，赋予权限之后，这个权限问题不会出现了，但是还是无法正常备份，依然报错：

1
2

[root@tidb ~]# ossutil64 ls oss://csi-tidb-backup/
Error: Get http://csi-tidb-backup.oss-cn-shanghai.aliyuncs.com/?delimiter&encoding-type=url&marker&max-keys=1000&prefix: read tcp 10.207.38.40:37130->106.14.228.174:80: read: connection reset by peer, Bucket=csi-tidb-backup, Object=

后面又怀疑可能是这台主机有网络限制的原因，我在本地 Windows 测试了一下 ossutil，发现可以正常连接：

E:\ossutil>ossutil64 ls oss://csi-tidb-backup/
LastModifiedTime                   Size(B)  StorageClass   ETAG                                  ObjectName
2025-11-05 13:22:53 +0800 CST            0      Standard   D41D8CD98F00B204E9800998ECF8427E      oss://csi-tidb-backup/backup-data/
2025-11-05 13:23:06 +0800 CST            0      Standard   D41D8CD98F00B204E9800998ECF8427E      oss://csi-tidb-backup/backup-data/log-backup/
Object Number is: 2

0.822179(s) elapsed

这么看起来真可能是网络限制问题，咨询了一下网络组同事，看了一下拦截日志，发现有一个 IP 被拦截了，我看了下这个 IP [106.14.228.174]，发现很眼熟，ping 了一下：

1
2
3

[root@tidb ~]# ping csi-tidb-backup.oss-cn-shanghai.aliyuncs.com
PING csi-tidb-backup.oss-cn-shanghai.aliyuncs.com (106.14.228.174) 56(84) bytes of data.
^C

原来是 bucket 的域名没有放行，再返回去看，其实一开始报错就很明确的展示了，只是我选择性的忽略了，因为之前已经请网络组放行了 oss-cn-shanghai.aliyuncs.com 域名，默认就觉得网络这块已经没问题了，所以就不往那方面去考虑，但其实原因早就告诉我们了：read tcp 10.207.38.40:37130->106.14.228.174:80。

请网络组同事放行 csi-tidb-backup.oss-cn-shanghai.aliyuncs.com 域名之后，再次执行日志备份：

[root@tidb scripts]# sh brbackuplogaliyun.sh 
Detail BR log in brbackuplog-20251107150320.log 
[2025/11/07 15:03:21.642 +08:00] [INFO] [collector.go:77] ["log start"] [streamTaskInfo="{taskName=pitr,startTs=462028537971605515,endTS=999999999999999999,tableFilter=*.*}"] [pausing=false] [rangeCount=2]
[2025/11/07 15:03:21.643 +08:00] [INFO] [collector.go:77] ["log start success summary"] [total-ranges=0] [ranges-succeed=0] [ranges-failed=0] [backup-checksum=306.222299ms] [total-take=1.274043205s]

## 查看备份任务
[root@tidb ~]# br log status --pd "10.207.38.42:2379"
Detail BR log in /tmp/br.log.2025-11-07T15.43.55+0800 
● Total 1 Tasks.
> #1 <
              name: pitr
            status: ● NORMAL
             start: 2025-11-07 15:03:20.441 +0800
               end: 2090-11-18 22:07:45.624 +0800
           storage: s3://csi-tidb-backup/backup-data/log-backup
       speed(est.): 778.46 ops/s
checkpoint[global]: 2025-11-07 15:41:43.091 +0800; gap=2m14s

日志备份成功。

快照备份

执行快照备份：

1
2
3

[root@YCPTLMESTIDB01 scripts]# sh brbackupfullaliyun.sh 
Detail BR log in brbackupfull-20251107150353.log 
Full Backup <---------------------------------------------------------------------------------------> 5.81%

等待备份完成，阿里云 OSS 备份部署完成。

写在最后

最后，一首打油诗奉上：

版本对齐是个坑，升级工具才能通。权限一层又一层，RAM、OSS、防火墙。
网络安全诚可贵，拦截规则价更高。域名放行以为够，Bucket域名又被搞。
报错信息明明白，先入为主看不到。ping通telnet全都行，就是连不上云端。
本地测试一切好，服务器上就报错。排查三天头发掉，原来墙里有玄机。
安全重要人人知，层层设防理应该。可怜运维两行泪，复杂规则绕晕人。
OSS、S3 和 RAM，AK、SK 加 Endpoint。Virtual、Path 两种style，选错一个全白忙。
社区论坛翻个遍，日志文件看到瞎。最后发现真凶手，一条规则把路卡。
安全诚可贵，效率价更高；若为复杂死，两者皆可抛。

吐槽归吐槽，该配的安全还得配。只是希望规则能更透明些，文档能更清晰些，让我们少掉点头发吧！😭

文章作者: 三笠丶

文章链接: https://pc-study.github.io/2025/11/%E4%BD%BF%E7%94%A8%20BR%20%E5%A4%87%E4%BB%BD%20TiDB%20%E5%88%B0%E9%98%BF%E9%87%8C%E4%BA%91%20OSS%20%E5%AD%98%E5%82%A8/