I am facing below error while restoring gitlab from old backup.

gitlab-rake gitlab:backup:restore BACKUP=/var/opt/gitlab/backups/1684533991_2023_05_19_15.10.0

2023-05-20 12:29:05 UTC – Unpacking backup …
tar: Unexpected EOF in archive
tar: rmtlseek not stopped at a record boundary
tar: Error is not recoverable: exiting now
2023-05-20 12:47:09 UTC – Unpacking backup failed
2023-05-20 17:47:10 +0500 – Deleting backup and restore lock file

That looks like an issue with that specific backup. Does the same problem occur if you try to use another one (possibly after making one)?

We can only guess at what caused that corruption. Some things to check:

1. Does the system have enough free disk to make the backup (usage might temporarily o to three times the size of the result.
2. Is this backup significantly differently sized than the backups taken before/after this?

When searching for that error message (trying to find out what i means to have a better idea what is wrong), it stumbled upon:

so you’re not the first to encounter this, and it seems the solution was basically to try again.
There’s also

another similar report with nothing of interest in it.

Basically one week of backup files were corrupted and yes there was abnormality in size Suddenly backup size changed from 3 GB to 5 GB…
and although there were was enough space like 7-8 GB however i think storage was also a factor there

I couldnot resolve the issue (recover corrupted files)but instead i made new backup ,cleared some space and suddenly it was working fine…

7-8 GB doesn’t sound like much free space when the backup files are 3 (or 5 GB), do you have some metrics that allow you to see what you reach during backups?

Even though you made a backup that is working, finding out what was wrong can be a good learning experiences.
If you still have (some/one of) the corrupted files, can you show it/their size(s) together with the size of a good backup?
Perhaps tar vtf <corrupted-backup.tar> will show you enough (compare if with the same output from a good backup) that you can determine which of the constituent files got large?

No, I don’t have any metrics for such.

Old good backup was of 3.8 GB and suddenly backup sizes changed to 5.9 GB , Moreover that command results in error soon after it start it… same error as described before…
Certainly looks like a space issue as i had in mind that backup’s were of 3 GB but now they are of 6 GB