After truncating expired data in BR log backup, a large number of historical data files still exist on S3

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: br日志备份truncate过期数据后,s3上还是存在大量历史数据文件

| username: wfxxh

Periodically executing the br log truncate command shows that the earliest recoverable time has indeed changed, indicating that the truncate command was successfully executed.

| username: 大飞哥online | Original post link

There are parameters that can control the deletion of historical data, and you can also manually clean it up.

| username: wfxxh | Original post link

Which one are you talking about? tiup br log truncate --until=${FULL_BACKUP_TS}?
Look at my second screenshot, the truncate has already been executed.

| username: 大飞哥online | Original post link

It is br backup scheduled to delete historical backup records.

| username: zhanggame1 | Original post link

The backup itself should have been deleted, this is the backup information record.

| username: wfxxh | Original post link

The truncate command is used to delete expired records. Looking at the title of this post, I have already executed this command successfully, as shown in the second image where the earliest recoverable time is much later than in the first screenshot. My question is, after executing truncate, there is still historical information on S3.

| username: wfxxh | Original post link

Yes, the second image shows that the backup data itself has been deleted, but the metadata has not been deleted and has existed since my backup. Each file is over 4MB, and over time, it accumulates and takes up a significant amount of storage.

| username: tidb菜鸟一只 | Original post link

Execute the br log metadata command to check the results.

| username: Fly-bird | Original post link

S3 data can be manually deleted.

| username: wfxxh | Original post link

Not elegant enough.

| username: Daniel-W | Original post link

I also back up to S3 with version 6.5. I’ll check in production later to see if there’s the same issue.

| username: dba-kit | Original post link

It seems to be intentionally designed. Each time you execute truncate, the current backup metadata is stored as a log, and then the metadata is stored in a new file. If it is not archived once, it will be like mine, with only one file.

| username: wfxxh | Original post link

Uh, this probably didn’t take this situation into account. Otherwise, over time, it would accumulate and take up a lot of storage space.

| username: 像风一样的男子 | Original post link

Wouldn’t it be fine to set a data retention period on S3?

| username: wfxxh | Original post link

Automatically generated, how to set the expiration date? Modify it after generating it? Might as well just delete it all :grinning:

| username: 像风一样的男子 | Original post link

Set up automatic deletion in the S3 console.

| username: wfxxh | Original post link

We share the bucket, so we can’t set the bucket :joy:

| username: dba-kit | Original post link

The lifecycle can be set for a specific path.

| username: wfxxh | Original post link

We are not using standard AWS S3 :joy:

| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.