tiup br backup full --pd “${PD_IP}:2379”
–storage ‘s3://backup-101/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}’
这个指令的storage部分我目前知道的可以把s3换成local。
那么恢复的时候也会写这么一长串地址。如果我是在另外一个linux机器上可以ping通的我该怎么写呢
是使用类似这种命令 ```
scp 172.24.74.68:/tidb/backup/20211214/* .吗？
然后再在新的linux机器上用local么？
这里的s3只能用local的么？
local的有两种选择：
1、使用nfs，备份都备份到共享路径里面
2、使用scp，把每个节点的本地备份都给其他节点都传一份
1 个赞
就是不是一个集群。我另外起了一个新的集群这样子
s3是对象存储，需要专门的提供s3服务的服务器，在另外一个机器还原也一样，s3地址只要网络能通，账号密码对就可以访问，还原也是写一样的地址。
local 就是tikv本地目录，也可以是NFS目录。如果使用的是本地目录，要求所有节点都是相同的目录，而且必须把每个节点备份的内容全部拷贝到其他节点。
s3本身就不是local的。
参考：
TiDB 备份与恢复功能使用概述 | PingCAP 文档中心
选择备份存储
Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 是推荐的存储系统选择，使用这些系统，你无需担心备份容量、备份带宽规划等。
如果 TiDB 集群部署在自建机房中，则推荐以下方式：
- 搭建 MinIO 作为备份存储系统，使用 S3 协议将数据备份到 MinIO 中。
- 挂载 NFS（如 NAS）盘到 br 工具和所有的 TiKV 实例，使用 POSIX file system 接口将备份数据写入对应的 NFS 目录中。
注意
如果没有挂载 NFS 到 br 工具或 TiKV 节点，或者使用了支持 S3、GCS 或 Azure Blob Storage 协议的远端存储，那么 br 工具备份的数据会在各个 TiKV 节点生成。注意这不是推荐的 br 工具使用方式，因为备份数据会分散在各个节点的本地文件系统中，聚集这些备份数据可能会造成数据冗余和运维上的麻烦，而且在不聚集这些数据便直接恢复的时候会遇到 SST file not found 报错。
1 个赞
好的明白了谢谢。那如果是nfs这里要写什么
NFS 相当于是local
NFS就是操作系统上的一个目录，对应用程序而言可以理解为跟操作系统一样的目录。
NFS也需要一个server端，不过这个比较简单，比s3好弄，可以搜一下，网上很多介绍。
不过NFS在高并发的场景稳定性不足，有时会挂起，这是老问题。。一般情况下很少遇到。
可以参考如下案例
[root@localhost ~]# tiup br backup full --pd "192.168.0.100:2379" --storage "local:///tmp/backup4" --ratelimit 120 --log-file backupfull3.log
tiup is checking updates for component br ...
Starting component `br`: /root/.tiup/components/br/v7.5.0/br backup full --pd 192.168.0.100:2379 --storage local:///tmp/backup4 --ratelimit 120 --log-file backupfull3.log
Detail BR log in backupfull3.log
[2024/01/14 22:22:53.968 +08:00] [WARN] [backup.go:312] ["setting `--ratelimit` and `--concurrency` at the same time, ignoring `--concurrency`: `--ratelimit` forces sequential (i.e. concurrency = 1) backup"] [ratelimit=125.8MB/s] [concurrency-specified=4]
Full Backup <--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%
Checksum <-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00%
[2024/01/14 22:29:26.162 +08:00] [INFO] [collector.go:77] ["Full Backup success summary"] [total-ranges=563] [ranges-succeed=563] [ranges-failed=0] [backup-checksum=37.87673844s] [backup-fast-checksum=596.027937ms] [backup-total-ranges=646] [total-take=6m32.19307978s] [
BackupTS=447201206333341701] [total-kv=23077589] [total-kv-size=3.309GB] [average-speed=8.437MB/s] [backup-data-size(after-compressed)=1.165GB] [Size=1164606935]
[root@localhost ~]#
嗯嗯好的!!谢谢
除了s3还有什么协议支持吗？是不是使用了s3就不需要聚集这些数据了
Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 是推荐的存储系统选择，使用这些系统，你无需担心备份容量、备份带宽规划等。
没用过Google Cloud Storage (GCS)、Azure Blob Storage ，但是我查了都是s3协议的，就是对象存储。
其实还有很多自建的对象存储，因为都是起源自Amazon S3，所以我理解（非官方）应该是支持S3协议的对象存储都能用。
其他协议就是NFS了，没看到其他的介绍
使用了这些就不需要想存在本地一样进行整合了是吧
nfs就写挂载的路径把？
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。