如题，本人在做tidb完全备份和日志备份方案。
我使用tiup br log start命令指定共享目录开启日志备份之后，能看到目录中生成的各类文件。
我想知道能否实现一种操作，
比如每日一次，将当天产生的日志备份文件打包成一个备份集进行存储，再将本地的日志文件清除。
然后恢复的时候，先恢复完全备份，再将所有打包的备份集合并到一个目录中，进行PIRT恢复操作。
如果可以该如何操作，打包的文件如何合并？
感觉恐怕不是文件合并能解决的问题。
因为目录里面看应该是一堆sst文件，这可能可以理解为就是region的原始信息，而且带了备份时间开始到现在的所有mvcc信息来实现pitr。这个东西恐怕不是文件合并能解决的。
因为会有一些sst没写满，按天还原sst肯定有相互的覆盖，按天操作一个顺序搞错，恢复的日志就没法用了。
如果非要一天上传一次，我感觉保险点还是每天tiup br log stop之后备份掉，再按照时间戳启动一下任务，并且改变一下保存的路径。可能可以做到。
我也没试过。你可以尝试一下。
最好还是弄个s3.就非常省心了。你这么绕一圈折腾的原因，还是因为用的是共享目录。
1 个赞
弄个共享存储多方便，或者共享目录
打包的文件如何合并 ？
tar个包就行，不用合并吧
那日志怎么恢复？一个包一个包恢复吗？
tidb恢复流程你试试，看看有啥问题，需要完整备份加完整备份后的日志
大佬您好，有个问题想确认下，如果是全量+日志进行备份的话，使用共享目录时，由于日志备份是一天一次，那么恢复时先恢复全量的，但是增量数据存在多份，是需要恢复多次还是可以一次性恢复呢
这个不实际操作一下，很难回答。我个人感觉这样恢复很难，非常不靠谱。看看是否有其他大佬有好的实践。
tidb在我大脑装了芯片了吗？最新在想灾备的问题，发现论坛首页有好几篇文章。 
我昨天试了一下，可以先停止日志备份，再拷走所有日志打包。
恢复的时候从完全备份集开始一个一个恢复可以做到，只要保证ts连续。
但是可恢复到的时间跟备份时间会有几分钟的差距，不知道有没有强制checkpoint的操作，能否类似强制生成日志减少时间差距。
1 个赞
你是说恢复时先全量恢复一次，然后将增量数据按时间前后日期多次分批恢复吗？比如2024-05-01是全量备份，然后02、 03、 04 …，恢复时先全量恢复01之前的所有数据，然后执行02的恢复、03的恢复，依次类推，是这样吗
很好的实践
强制checkpoint操作没有。
https://docs.pingcap.com/zh/tidb/stable/br-pitr-manual#查看备份数据元信息
但是可以通过br log metadata命令，确保最近的可恢复时间点，包含之前完整的一天。不过想要精准控制按秒级划分的话，可能确实有点难。
是的，只要备份集TS保证小于上一个备份集结束TS就可以按顺序恢复
如果这样的话，当增量数据目录日期过多时，感觉恢复还是挺繁琐的，不可能一天一天的恢复吧？
最近的一次全量备份之后的日期，应该只能一天一天恢复，日志备份目录里记录了备份源数据信息应该没法合并。
好吧，这样确实有点不太方便。只能尽量增加全量备份的频率减少增量目录的数量了
这种恢复其实不推荐
可以采用操作系统的rsync工具试试，远程传输很好用。