在知识库中专注阅读，并随时返回相关工具与课程
@TOC目录 最近好久没更新 Oracle 相关内容了，都在搞备份的东西，为啥呢？ 因为最近 Oracle 相关的内容都是很基础的，也没有遇到什么问题，所以就自然没什么内容可写了，反倒是最近几天都在研究 TiDB 备份，顺便学习了下 TiDB 的体系结构以及各种组件，也是比较有收获的。 话说回来，书接上篇 使用 BR 备份 TiDB 到 AWS S3 存储https://www.modb.pro/
本章目标：掌握本章核心知识点 前置要求：完成前序章节学习 预计时长：60 分钟
最近好久没更新 Oracle 相关内容了，都在搞备份的东西，为啥呢？
因为最近 Oracle 相关的内容都是很基础的，也没有遇到什么问题，所以就自然没什么内容可写了，反倒是最近几天都在研究 TiDB 备份，顺便学习了下 TiDB 的体系结构以及各种组件，也是比较有收获的。
话说回来，书接上篇 使用 BR 备份 TiDB 到 AWS S3 存储 备份到 AWS S3，部署完之后发现快照备份执行到一半还是会失败，分析后说原因可能是 AWS 公网络延迟导致的，到最后也没解决。
所以又换了阿里云 OSS 测了一下，今天也记录一下测试过程中遇到的一些问题，虽说最后也没成功。
在阿里云上创建 OSS 存储部分不是我操作的，所以没有记录，我这边是直接获取到了 OSS 存储的 Bucket、AK/SK 信息以及 Endpoint，有这些信息就可以了。
为了验证是否可以正常连接阿里云 OSS 存储，可以下载 oss-browser 或者 S3 Browser，输入上面获取到的信息就可以连接到阿里云 OSS 存储：
如果使用 S3 Browser 记得要选择 Virtual hosted style：
阿里云 OSS 不支持 Path style，会报错：
连接后可以看到创建好的 OSS 存储以及里面的内容，测试可以正常上传文件：
至此，阿里云 OSS 存储验证正常。
日志备份是一个 task，所以只需要启动一次即可：
1[root@tidb ~]# cat<<-EOF>/root/scripts/brbackuplog.sh2AccessKey="根据实际情况填写"3SecretKey="根据实际情况填写"4Bucket="根据实际情况填写"5Endpoint="根据实际情况填写"6PDIP="根据实际情况填写"7export AWS_ACCESS_KEY_ID=$AccessKey8export AWS_SECRET_ACCESS_KEY=$SecretKey9CURDATE=$(date +%Y%m%d%H%M%S)10br log start --task-name=pitr \11--pd "${PDIP}" \12--storage "s3://${Bucket}/backup-data/log-backup" \13--s3.endpoint="https://${Endpoint}" \14--s3.provider="alibaba" \15--log-file brbackuplog-$CURDATE.log1617echo s3://${Bucket}/backup-data/log-backup18EOF启动日志备份任务：
1[root@tidb ~]# chmod +x /root/scripts/brbackuplog.sh2[root@tidb ~]# sh /root/scripts/brbackuplog.sh很不幸，执行报错了：
1Error: 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，可以参考以下问答：
是因为在 provider 是 alibaba 的情况下，没有使用到环境变量中 AK/SK 的问题导致的这个报错，但是在 BR v7.5.3 版本已经进行修复：
所以只需要将 BR 升级到 v7.5.3 以上版本即可避免这个问题，我这里选择小版本用最新的 v7.5.7 版本：
1[root@tidb ~]# wget https://tiup-mirrors.pingcap.com/br-v7.5.7-linux-amd64.tar.gz2[root@tidb ~]# tar -xf br-v7.5.7-linux-amd64.tar.gz -C /usr/sbin/3[root@tidb ~]# br --version4Release Version: v7.5.7这里提一嘴：因为我 TiDB 集群 v7.5.0 版本的限制，所以选择了跟 TiDB 集群版本相同的 BR 版本，其实这是个思维误区，其实应该选择小版本最新，避免这些已经被修复的 BUG。
这个问题解决了，重新执行日志备份任务，又报错了：
1Error: RequestError: send request failed2caused 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 端口又是通的：
1[root@tidb ~]# telnet 106.14.228.174 4432Trying 106.14.228.174...3Connected to 106.14.228.174.4Escape character is '^]'.后来在 TiDB 社区提了个问题，跟社区朋友们讨论了一下，有了一些头绪，怀疑不是 BR 工具本身的问题，有可能是 这台 Linux 主机本身就不能访问 OSS，使用 ossutil64 测了一下能不能直接连接 OSS 存储：
1[root@tidb ~]# ossutil64 ls oss://csi-tidb-backup/2Error: 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[root@tidb ~]# ossutil64 ls oss://csi-tidb-backup/2Error: 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，发现可以正常连接：
1E:\ossutil>ossutil64 ls oss://csi-tidb-backup/2LastModifiedTime Size(B) StorageClass ETAG ObjectName32025-11-05 13:22:53 +0800 CST 0 Standard D41D8CD98F00B204E9800998ECF8427E oss://csi-tidb-backup/backup-data/42025-11-05 13:23:06 +0800 CST 0 Standard D41D8CD98F00B204E9800998ECF8427E oss://csi-tidb-backup/backup-data/log-backup/5Object Number is: 2670.822179(s) elapsed这么看起来真可能是网络限制问题，咨询了一下网络组同事，看了一下拦截日志，发现有一个 IP 被拦截了，我看了下这个 IP [106.14.228.174]，发现很眼熟，ping 了一下：
1[root@tidb ~]# ping csi-tidb-backup.oss-cn-shanghai.aliyuncs.com2PING csi-tidb-backup.oss-cn-shanghai.aliyuncs.com (106.14.228.174) 56(84) bytes of data.3^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 域名之后，再次执行日志备份：
1[root@tidb scripts]# sh brbackuplogaliyun.sh 2Detail BR log in brbackuplog-20251107150320.log 3[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]4[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]56## 查看备份任务7[root@tidb ~]# br log status --pd "10.207.38.42:2379"8Detail BR log in /tmp/br.log.2025-11-07T15.43.55+0800 9● Total 1 Tasks.10> #1 <11 name: pitr12 status: ● NORMAL13 start: 2025-11-07 15:03:20.441 +080014 end: 2090-11-18 22:07:45.624 +080015 storage: s3://csi-tidb-backup/backup-data/log-backup16 speed(est.): 778.46 ops/s17checkpoint[global]: 2025-11-07 15:41:43.091 +0800; gap=2m14s日志备份成功。
执行快照备份：
1[root@YCPTLMESTIDB01 scripts]# sh brbackupfullaliyun.sh 2Detail BR log in brbackupfull-20251107150353.log 3Full Backup <---------------------------------------------------------------------------------------> 5.81%等待备份完成，阿里云 OSS 备份部署完成。
最后，一首打油诗奉上：
版本对齐是个坑，升级工具才能通。权限一层又一层，RAM、OSS、防火墙。 网络安全诚可贵，拦截规则价更高。域名放行以为够，Bucket域名又被搞。 报错信息明明白，先入为主看不到。ping通telnet全都行，就是连不上云端。 本地测试一切好，服务器上就报错。排查三天头发掉，原来墙里有玄机。 安全重要人人知，层层设防理应该。可怜运维两行泪，复杂规则绕晕人。 OSS、S3 和 RAM，AK、SK 加 Endpoint。Virtual、Path 两种style，选错一个全白忙。 社区论坛翻个遍，日志文件看到瞎。最后发现真凶手，一条规则把路卡。 安全诚可贵，效率价更高；若为复杂死，两者皆可抛。
吐槽归吐槽，该配的安全还得配。只是希望规则能更透明些，文档能更清晰些，让我们少掉点头发吧！😭