tarExtract pipeline error: Invalid tar header
-
Yes, I got the error mentioned before on a newly created backup without encryption. The tarball was around 13 GB.
I was only able to restore backups older than 1 month for the nextcloud app. For all other 12+ apps restoring did work like a charme for the most recent backup (younger than 1 month).
It gives me the impression that the CIFS with Hetzner Storagebox is a risky choice.
Therefore, a hint in the docs might be saving some lives of other folks.I would like to offer 2 additional feedbacks beyond the CIFS issue and the docs:
- it seems to be not possible to use the decryption command line cloudron command with a password that includes special characters. I tried to escape with " but it didn't work. Probably sth to document. Maybe there is a way to escape after all.
- Is there any way to do backup validation? It is probably concerning to see successful backups while they are corrupt.
And thanks a lot for the support @girish and @nebulon for pointing me in the right direction! I resolved it by choosing a different cloud provider and different storage protocol. I used S3 now. Backing up and restoring worked with encryption completely fine!
Thank you!@nottheend said in tarExtract pipeline error: Invalid tar header:
It gives me the impression that the CIFS with Hetzner Storagebox is a risky choice.
I've been using it pretty much without issue for a good couple of years now, including doing a couple of complete restores.
But: I don't use encryption. I've always taken the veiw that issues relating to having troubls decrypting - eg forgetting passphrase, some corruption etc etx - are a bigger risk for me losing data than someone somehow gaining access to my Storage Boxes, in part because I don't have particularly sensitive data stored.
-
Hetzner's box, SSHFS with encryption - recovery fails with:
2024-10-19T13:37:34.456Z box:provision setProgress: restore - Downloading backup /mnt/cloudronbackup/my_domain_cloudron/2024-10-19-130519-879/box_v8.0.6.tar.gz.enc 2024-10-19T13:37:34.456Z box:storage/filesystem download: /mnt/cloudronbackup/my_domain_cloudron/2024-10-19-130519-879/box_v8.0.6.tar.gz.enc 2024-10-19T13:37:34.547Z box:backupformat/tgz Attempt 2 failed. Will retry: tarExtract pipeline error: incorrect header check
Checking the file:
file /mnt/cloudronbackup/my_domain_cloudron/2024-10-19-130519-879/box_v8.0.6.tar.gz.enc /mnt/cloudronbackup/my_domain_cloudron/2024-10-19-130519-879/box_v8.0.6.tar.gz.enc: data
Guess encrypted data can't have tar headers?
-
in my specific case - that was due to decryption key error
-
G girish has marked this topic as solved on
-
Hello everyone,
restoring Wordpress Developer instance, I had this problem right now:
May 09 13:54:41 box:backupformat/tgz tarExtract: ./data/public/wp-content/uploads/2015/02/filename.jpg 73444 file to /home/yellowtent/appsdata/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/data/public/wp-content/uploads/2015/02/filename.jpg May 09 13:54:41 box:apptask run: app error for state pending_restore: BoxError: tarExtract pipeline error: invalid stored block lengths at tarExtract (/home/yellowtent/box/src/backupformat/tgz.js:225:26) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) at async /home/yellowtent/box/src/backupformat/tgz.js:248:9 at async promiseRetry (/home/yellowtent/box/src/promise-retry.js:17:20) at async Object.download (/home/yellowtent/box/src/backupformat/tgz.js:244:5) at async download (/home/yellowtent/box/src/backuptask.js:104:5) at async Object.downloadApp (/home/yellowtent/box/src/backuptask.js:138:5) at async install (/home/yellowtent/box/src/apptask.js:368:9) { reason: 'External Error', details: {} } May 09 13:54:41 box:tasks setCompleted - 681: {"result":null,"error":{"stack":"BoxError: tarExtract pipeline error: invalid stored block lengths\n at tarExtract (/home/yellowtent/box/src/backupformat/tgz.js:225:26)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async /home/yellowtent/box/src/backupformat/tgz.js:248:9\n at async promiseRetry (/home/yellowtent/box/src/promise-retry.js:17:20)\n at async Object.download (/home/yellowtent/box/src/backupformat/tgz.js:244:5)\n at async download (/home/yellowtent/box/src/backuptask.js:104:5)\n at async Object.downloadApp (/home/yellowtent/box/src/backuptask.js:138:5)\n at async install (/home/yellowtent/box/src/apptask.js:368:9)","name":"BoxError","reason":"External Error","details":{},"message":"tarExtract pipeline error: invalid stored block lengths"}} May 09 13:54:41 box:tasks update 681: {"percent":100,"result":null,"error":{"stack":"BoxError: tarExtract pipeline error: invalid stored block lengths\n at tarExtract (/home/yellowtent/box/src/backupformat/tgz.js:225:26)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async /home/yellowtent/box/src/backupformat/tgz.js:248:9\n at async promiseRetry (/home/yellowtent/box/src/promise-retry.js:17:20)\n at async Object.download (/home/yellowtent/box/src/backupformat/tgz.js:244:5)\n at async download (/home/yellowtent/box/src/backuptask.js:104:5)\n at async Object.downloadApp (/home/yellowtent/box/src/backuptask.js:138:5)\n at async install (/home/yellowtent/box/src/apptask.js:368:9)","name":"BoxError","reason":"External Error","details":{},"message":"tarExtract pipeline error: invalid stored block lengths"}} May 09 13:54:41 box:taskworker Task took 335.441 seconds May 09 13:54:41 BoxError: tarExtract pipeline error: invalid stored block lengths
Many others file was extracted... but then stopped with this error:
BoxError: tarExtract pipeline error: invalid stored block lengths at tarExtract
and
External Error: tarExtract pipeline error: Invalid tar header. Maybe the tar is corrupted or it needs to be gunzipped?
Edit:
I confirm that is something Hetzner Box related (Via CIFS).
I changed to Backblaze and everything is fine. -
Hopefully it will not appear with any storage anymore when this is implemented:
(9.0) Backup integrity - store size and checksum of backups. Also provide a way to "verify" backup integrity in the remote.
Mentioned in
what's coming in cloudron 9 -
@nottheend ok thanks a lot
-
-
Again, handling a "tarExtract pipeline error: incorrect header check" issue... on a different backup... very very sad for this... I hope you can release soon a solution because is risky to store backups that then cannot be restored @girish
@p44 for encrypted backups, not sure what is the expected behaviour. If the backup is corrupt or password is forgotten, one cannot recover. What do you have in mind? What do you think Cloudron could have done? (or was your note about adding periodic integrity checks?)
-
Periodic integrity checks – for example, verifying the backup archive and reporting issues proactively – could help discover corruption early, before a restore is needed. This would give admins a chance to re-run or fix backups in time.
What do you think about such a feature?
-
-
Hi all, I'm still getting this error on Hetzner Storage Box:
"tarExtract pipeline error: invalid block type"
Even on a same backup did few minutes before, I had this error.
I moved away -
Hello @p44
Could you please check thebox.log
and the backup log for error messages?
If you find something, please post this error message here.
I will try to investigate and with enough data I can even contact Hetzner directly, if the issue seems to be specific to Hetzner Storage Boxes. -
Hello @p44
Could you please check thebox.log
and the backup log for error messages?
If you find something, please post this error message here.
I will try to investigate and with enough data I can even contact Hetzner directly, if the issue seems to be specific to Hetzner Storage Boxes. -
@james Thanks a lot, I found this:
2025-07-20T18:54:47.274Z box:tasks startTask: 1458 done. error: { stack: 'BoxError: tarExtract pipeline error: invalid block type\n' + ' at tarExtract (/home/yellowtent/box/src/backupformat/tgz.js:225:26)\n' + ' at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n' + ' at async /home/yellowtent/box/src/backupformat/tgz.js:248:9\n' + ' at async promiseRetry (/home/yellowtent/box/src/promise-retry.js:17:20)\n' + ' at async Object.download (/home/yellowtent/box/src/backupformat/tgz.js:244:5)\n' + ' at async download (/home/yellowtent/box/src/backuptask.js:104:5)\n' + ' at async Object.downloadApp (/home/yellowtent/box/src/backuptask.js:138:5)\n' + ' at async install (/home/yellowtent/box/src/apptask.js:368:9)', name: 'BoxError', reason: 'External Error', details: {}, message: 'tarExtract pipeline error: invalid block type' }
Other specific backup logs were rotated.
Maybe Hetzner do some kind of compression on the file, or manipulation? (https://stackoverflow.com/questions/76818505/why-is-the-disk-usage-on-the-hetzner-storage-box-less-than-on-the-hetzner-dedica)
Edit: I found also these posts that mentioned errors, the first one with .tar.gz:
- https://forum.rclone.org/t/files-corrupted-with-hetzner-storage-box/39016
- https://www.reddit.com/r/hetzner/comments/1ihlhhp/corrupted_files_in_storage_box_mounted_as_smb/
While we try to understand this better, I would suggest not using the Hetzner Storage Box as primary backup.
Edit2: @james keep us posted about directly contact with Hetzner.
-
@james Thanks a lot, I found this:
2025-07-20T18:54:47.274Z box:tasks startTask: 1458 done. error: { stack: 'BoxError: tarExtract pipeline error: invalid block type\n' + ' at tarExtract (/home/yellowtent/box/src/backupformat/tgz.js:225:26)\n' + ' at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n' + ' at async /home/yellowtent/box/src/backupformat/tgz.js:248:9\n' + ' at async promiseRetry (/home/yellowtent/box/src/promise-retry.js:17:20)\n' + ' at async Object.download (/home/yellowtent/box/src/backupformat/tgz.js:244:5)\n' + ' at async download (/home/yellowtent/box/src/backuptask.js:104:5)\n' + ' at async Object.downloadApp (/home/yellowtent/box/src/backuptask.js:138:5)\n' + ' at async install (/home/yellowtent/box/src/apptask.js:368:9)', name: 'BoxError', reason: 'External Error', details: {}, message: 'tarExtract pipeline error: invalid block type' }
Other specific backup logs were rotated.
Maybe Hetzner do some kind of compression on the file, or manipulation? (https://stackoverflow.com/questions/76818505/why-is-the-disk-usage-on-the-hetzner-storage-box-less-than-on-the-hetzner-dedica)
Edit: I found also these posts that mentioned errors, the first one with .tar.gz:
- https://forum.rclone.org/t/files-corrupted-with-hetzner-storage-box/39016
- https://www.reddit.com/r/hetzner/comments/1ihlhhp/corrupted_files_in_storage_box_mounted_as_smb/
While we try to understand this better, I would suggest not using the Hetzner Storage Box as primary backup.
Edit2: @james keep us posted about directly contact with Hetzner.
@p44 said in tarExtract pipeline error: Invalid tar header:
While we try to understand this better, I would suggest not using the Hetzner Storage Box as primary backup.
Is this just when using encryption?
I don't use encryption, but I've been using Hetzner Storage Boxes for about 6.5 years now without issue so far, including a few complete server migrations with no issues.
-
@p44 said in tarExtract pipeline error: Invalid tar header:
While we try to understand this better, I would suggest not using the Hetzner Storage Box as primary backup.
Is this just when using encryption?
I don't use encryption, but I've been using Hetzner Storage Boxes for about 6.5 years now without issue so far, including a few complete server migrations with no issues.
@jdaviescoates Yes, with encryption. Me too, I never had issues with Hetzner Storage Boxes but since few months various problem happens...