BR Restore Error

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

Original topic: br恢复报错

| username: 滴滴嗒嘀嗒

Using BR for backup, all backup data is imported into a single file during the backup process. When restoring, the corresponding data is sent to BR based on the file name requested by BR. Then BR reports an error: parse backupmeta failed because of wrong aes cipher: unexpected EOF.
image
Is there an issue with the data I provided, or is there another problem?

| username: Jasper | Original post link

I didn’t quite understand. Did you combine multiple backupmeta files into one? In that case, BR probably won’t recognize it.

| username: 这里介绍不了我 | Original post link

Could you please share the command?

| username: 滴滴嗒嘀嗒 | Original post link

There isn’t much to it. Basically, I merged all the files generated by the backup into one. Then, during the restoration, I can find the corresponding data through these file names.

| username: 滴滴嗒嘀嗒 | Original post link

Restore command?
/root/.tiup/components/br/v6.5.2/br restore full --pd 192.168.21.3:50001 --storage /home/ry/fuse/test/

| username: 这里介绍不了我 | Original post link

Compare this document to see if there is an issue with the local path, missing a “local”:

| username: Kongdom | Original post link

The files generated by the backup should not be manually merged. If manually merged, they might not be recognized during restoration. BR supports automatic merging, so manual merging is not necessary.

| username: Jellybean | Original post link

The BR tool automatically records the relevant file directories and metadata information when exporting data. If you have manually operated on the backup directory and related content, it may cause inconsistencies with the automatically recorded metadata, which can lead to recovery anomalies.

Try not manually merging and directly use the data backed up by BR to verify the recovery.

| username: 滴滴嗒嘀嗒 | Original post link

Where is the record of “BR tool exporting data will automatically record the relevant file directory and metadata information”?

| username: oceanzhang | Original post link

I feel more like it’s a bug.

| username: oceanzhang | Original post link

I think the first thing is to determine whether the backup is complete and whether there were any errors during the initial backup.

| username: oceanzhang | Original post link

If the backup is complete and there are no errors, but an error occurs in the middle of the restoration process, this should be a bug.

| username: 滴滴嗒嘀嗒 | Original post link

This can be confirmed. I have compared the sizes of all the data, and I have also printed out the character data to check. Everything matches up.

| username: 哈喽沃德 | Original post link

Check the integrity of the backup files.

| username: oceanzhang | Original post link

That is probably a bug.

| username: 滴滴嗒嘀嗒 | Original post link

How can this be detected? I have merged the data from all the backup files into one file.

| username: Jellybean | Original post link

When you back up to a specified storage directory path, such as storing to S3, use the corresponding --storage option.

| username: Jasper | Original post link

First, try to see if you can restore successfully without performing the “merge” operation you mentioned. It seems like the directories and such are not placed according to the default settings of BR, so the meta file is being parsed incorrectly.

| username: dba远航 | Original post link

During BR recovery, each node is required to have all the backup SST data files.

| username: zhanggame1 | Original post link

You can merge them. How did you merge them? I suggest creating a new directory and then copying everything into it.