Fig. TiKV backup with different CLI tools (and their problems).
水平及维护精力所限，文中不免存在错误或过时之处，请酌情参考。 传播知识，尊重劳动，年满十八周岁，转载请注明出处。
1 JuiceFS 元数据备份方式再复习下 JuiceFS 架构，如下图所示：
Fig. JuiceFS cluster initialization, and how POSIX file operations are handled by JuiceFS.
JuiceFS 的元数据都存储在元数据引擎（例如，TiKV）里， 因此元数据的备份有两种实现方式：
下面分别看看这两种方式。
2 JuiceFS 自带方式（volume 级别） 2.1 juicefs dump 手动备份 volume metadata对指定 volume 进行备份，
$ juicefs dump tikv://ip:2379/foo-dev foo-dev-dump.json <INFO>: Meta address: tikv://<ip>:2379/foo-dev [interface.go:406] <WARNING>: Secret key is removed for the sake of safety [tkv.go:2571] Scan keys count: 357806 / 357806 [===========================] done Dumped entries count: 122527 / 122527 [===========================] done <INFO>: Dump metadata into dump succeed [dump.go:76]生成的是一个 JSON 文件，包含了 volume 的所有元数据信息，
{ "Setting": { "Name": "foo-dev", "UUID": "ca95c258", "Storage": "OSS", "Bucket": "http://<url>", "AccessKey": "ak", "BlockSize": 4096, "Capacity": 0, "Inodes": 0, "MetaVersion": 0, "MinClientVersion": "", "MaxClientVersion": "", }, "Counters": { "usedSpace": 6164512768, "usedInodes": 5010, "nextInodes": 10402, "nextChunk": 25001, "nextSession": 118, }, "FSTree": { "attr": {"inode":1,"type":"directory","mode":511,"atime":1645791488,"mtime":1652433235,"ctime":1652433235,"mtimensec":553010494,"ctimensec":553010494,"nlink":2,"length":0}, "xattrs": [{"name":"lastBackup","value":"2024-05-30T13:50:25+08:00"}], "entries": { "001eb8b": { "attr": {...}, "chunks": [{"index":0,"slices":[{"chunkid":15931,"size":32,"len":32}]}] ... } } }, }其中，volume 中的所有文件和目录信息都描述在 FSTree 字段中。
2.2 juicefs mount --backup-meta <duration> 自动备份juicefs client 默认会自动备份 volume 的元数据，
根据官方文档，以上两种方式都有一些限制或问题：
另外，以上方式都是 volume 级别的备份，如果要备份整个 JuiceFS 集群，需要逐个 volume 备份，比较麻烦。 下面再看看直接从元数据引擎进行备份的方式。
3 从 TiKV 层面对 JuiceFS 元数据进行备份这里假设 JuiceFS 的元数据引擎是 TiKV。
3.1 TiKV backup/restore 原理从上层来说，很简单：
发请求给 TiKV 集群的管理者 PD，让它对集群的所有数据进行备份；
接下来，PD 会发请求给集群的所有 TiKV 节点，通知它们各自进行备份
TiKV region leaders 把这个 region 内的数据写到指定位置。可以是本地磁盘或分布式存储。
理论上，有两个工具可能实现以上效果，它们分别来自 TiDB 和 TiKV 社区，
Fig. TiKV backup with different CLI tools (and their problems).
br：以前是个独立项目（图中 A.1），后来合到 tidb 仓库里了（图中 B.1），
这个工具主要是给 TiDB 备份用的（虽然底层备份的是 TiDB 的 TiKV）， 所以需要一些 TiDB 知识（上下文），例如 db/table 都是 TiDB 才有的概念。 理论上，它也能备份独立部署的 TiKV 集群（“不依赖 TiDB 的 TiKV”）， 所以加了 raw/txn 支持，但不是 TiDB 社区的重点，所以目前还是 experimental 特性，且用下来有 bug。
tikv-br：是个独立项目，应该是当时 TiKV 作为独立项目推进时，想搞一个配套的独立备份工具， 但目前看起来跟 TiKV 社区一样已经不活跃了，它也没法对 txn 进行备份（JuiceFS 用的 txnkv 接口）。
至少对于 5.x TiKV 集群，测试下来以上哪个工具都无法完成备份： 有的工具备份和恢复都提示完成，看起来是成功的，但实际上是失败的，JuiceFS 挂载时才能发现。
最后，我们是基于目前（2024.09）最新的 TiDB br，修改了两个地方，才成功完成 TiKV 的备份与恢复。
3.3 基于 TiDB br 对 JuiceFS TiKV 集群进行备份与恢复的步骤之所以要强调 “JuiceFS TiKV 集群”，是因为 JuiceFS 用的 txnkv 接口，这个比较特殊； 如果是 rawkv 接口，那 tikv 自带的备份工具 tikv-br 也许就能用了（没测过）。
br 执行备份，
br-dev 是我们基于最新 master（202409）改过的版本。
$ ./br-dev backup txn \ --ca /tmp/pki/root.crt --cert /tmp/pki/pd.crt --key /tmp/pki/pd.key \ --pd https://$pd_addr \ --s3.endpoint $s3_addr \ --storage $storage_path \ --log-file /var/log/tikv/br.log \ --ratelimit $bw_limit_per_node \ --log-level debug \ --check-requirements=false可以设置限速等参数，避免备份占用的 CPU/Memory/DiskIO/… 过大。根据 db size 等等因素，备份的耗时是可估算的，下面拿一个真实集群的备份为例：
根据以上参数，估算耗时：25GB * 2 / 30MBps = 1700s = 28min
Fig. TiKV backup resource usage with br --ratelimit=30MB/s.
可以看到跟预估的差不多。资源销毁方面：
检查备份
如果是备份到 S3，可以用 s3cmd 或 web 控制台查看，
$ s3cmd du s3://{bucket}/<backup>/ 295655971082 18513 objects s3://{bucket}/<backup>/290GB 左右，比监控看到的 DB size 大一倍，因为保留了 MVCC 多版本。 大多少倍与 MVCC GC 间隔有密切关系， 比如写或更新很频繁的场景，1h 和 3h 的 MVCC 数据量就差很多了。
br 恢复：将备份数据恢复到一个新的 JuiceFS TiKV 集群，
$ ./br-dev restore txn \ --ca /tmp/pki/root.crt --cert /tmp/pki/pd.crt --key /tmp/pki/pd.key \ --pd https://$pd_addr \ --s3.endpoint $s3_addr \ --storage $storage_path \ --log-file /var/log/tikv/br.log \ --ratelimit $bw_limit_per_node \ --log-level debug \ --check-requirements=false可能的问题：ratelimit 好像不起作用，全速恢复，网络带宽打的很高。
JuiceFS client 挂载，验证恢复成功
用 juicefs 挂载目录，指定新 TiKV 集群的 PD 地址，
$ juicefs mount tikv://<new-pd-ip>:2379/<volume name> /tmp/test $ cd /tmp/test && ls # 原来 volume 内的文件都在感兴趣的可以看看 br 源码的备份逻辑，
3.4.1 RunBackupTxn() // tidb br/pkg/task/backup_txn.go // RunBackupTxn starts a backup task inside the current goroutine. func RunBackupTxn(c context.Context, g glue.Glue, cmdName string, cfg *TxnKvConfig) error { mgr := NewMgr(ctx, g, cfg.PD, cfg.TLS, GetKeepalive(&cfg.Config), cfg.CheckRequirements, false) client := backup.NewBackupClient(ctx, mgr) backupRanges := make([]rtree.Range, 0, 1) // current just build full txn range to support full txn backup minStartKey := []byte{} maxEndKey := []byte{} backupRanges = append(backupRanges, rtree.Range{ StartKey: minStartKey, EndKey: maxEndKey, }) // Backup req := backuppb.BackupRequest{ ClusterId: client.GetClusterID(), StartVersion: 0, EndVersion: client.GetCurrentTS(ctx), // gets a new timestamp (TSO) from PD RateLimit: cfg.RateLimit, Concurrency: cfg.Concurrency, StorageBackend: client.GetStorageBackend(), IsRawKv: false, } ranges, schemas, policies := client.BuildBackupRangeAndSchema(mgr.GetStorage(), cfg.TableFilter, backupTS, isFullBackup(cmdName)) // StartWriteMetasAsync writes four kind of meta into backupmeta. // 1. file // 2. schema // 3. ddl // 4. rawRange( raw kv ) metaWriter := metautil.NewMetaWriter(client.GetStorage(), metautil.MetaFileSize, false, metautil.MetaFile, &cfg.CipherInfo) metaWriter.StartWriteMetasAsync(ctx, metautil.AppendDataFile) // Start TiKV backup client.BackupRanges(ctx, backupRanges, req, 1, nil, metaWriter, progressCallBack) // Backup has finished metaWriter.Update(func(m *backuppb.BackupMeta) { m.StartVersion = req.StartVersion m.EndVersion = req.EndVersion m.IsRawKv = false m.IsTxnKv = true m.ClusterId = req.ClusterId m.ClusterVersion = mgr.GetClusterVersion(ctx) m.BrVersion = brVersion m.ApiVersion = client.GetApiVersion() }) metaWriter.FinishWriteMetas(ctx, metautil.AppendDataFile) metaWriter.FlushBackupMeta(ctx) }几点说明：
The post Third-Party Pitfalls: Securing Private Data in Government Operations appeared first on Votiro.
The post Third-Party Pitfalls: Securing Private Data in Government Operations appeared first on Security Boulevard.