Extended header errors when restoring backups

cprompt

cprompt

Verified User
Joined
Sep 27, 2004
Messages
57
Location
Bristol, UK
I am having a similar problem restoring a backup from one DA server to another as describe here:
http://www.directadmin.com/forum/showthread.php?t=20814

Restoring the backup at reseller level I am pulling the file from the other server directly.
I get this error on tyring to restore:

Unable to extract the directory 'backup' from the file /home/tmp/host15/dauser48.tar.gz

I have downloaded the tar.gz file and unpacked it manually and it looks fine.
When I try to unpack the file on the server itself to a scratch directory "unpack" I get this:

[root@server2 user_backups]# tar xzfp dauser48.tar.gz -C unpack
tar: Ignoring unknown extended header keyword `SCHILY.dev'
tar: Ignoring unknown extended header keyword `SCHILY.ino'
tar: Ignoring unknown extended header keyword `SCHILY.nlink'
tar: Error exit delayed from previous errors

If I create the user concerned manually on the new server then backup and restore it works fine so I am wondering if I've got a problem here with different environments. Still its only a tar file so I can't understand why it wont unpack on the server itself.

Diskspace on the new server is plentiful.
The same tar.gz file will restore without problems to the server it was made on.

Does anyone have any ideas?

Many thanks in advance.
 
Last edited:
I've Googled on those extended headers errors and it seems it is a bug in TAR for BSD?
More info here:
http://www.nabble.com/bug-in-BSD-tar--t3830496.html

To reinforce this I have now restored this backup to another FreeBSD based DA server with no problems. It is failing with these extended header errors on two Centos based DA VPS's.
I downloaded the backup to an XP workstation and unpacked and then repackaged the tar using IZARc and the newly created TAR restored OK to the Centos based VPS's.
It's interesting to note that under SSH the errors are for information only but it's enough for the DA script to crash out before the restore is finished. Perhaps this needs to be addressed by Direct Admin?
 
Hello,

DirectAdmin will halt any restore if the tar ouput is anything but a return code of 0. We don't want to restore any corrupted data.

Based on reading the output, the issue is both tar's think they're right.. I'd say this probably goes past what DA should need to worry about, as one tar or the other isn't "following the rules" or protocols for what a tar.gz file should be. Probably installing the "gnutar" on freebsd would be the simplest fix so that the tar.gz files work on all OS's.

To see what you have, type:
Code: 
server# [b]tar --version[/b]
bsdtar 1.02.023, libarchive 1.02.026
Copyright (C) 2003-2005 Tim Kientzle
which would be what FreeBSD would come with.
This would be from a Fedora 7 system:
Code: 
[root@server ~]# [b]tar --version[/b]
tar (GNU tar) 1.15.1
I've googled around.. so on freebsd, try typing:
Code: 
pkg_add -r gtar
and see what that does.

John
 
Thanks for looking into this John.
Trouble is, on the FreeBSD box producing the backups, I only have reseller access - it's not my server. :-(
The two boxes I am restoring to are VPS that are mine but as they are Centos the issue isn't at their end.
I guess I'll have to bother the owner of the BSD server or put up with manually re-creating the tars.
Once again thanks for investigating.
 
I think this is more than a simple gnutar vs bsd version of tar error.

Why?

Because I get this error when attempting to restore a reseller backup:
Unable to extract the directory 'backup' from the file /home/main/user_backups/main.tar.gz

Unable to read the backed up user.usage file
Click to expand...
We're trying to move 35 users / 85 domains, from an older system running on RHL 9 to a new system running CentOS4.

Could this be the same error? Has anyone seen this?

The individual user backups work but they're incredibly time-consuming.

Any ideas?

Thanks.

Jeff
 
Thanks for your response, John.

The box owner has requested that I do that in a private message; since I can't PM you, please look for it in an email from me.

Thanks.

Jeff
 
John,

I just got back to this today. I really need to move this reseller backup to a new machine by the end of this weekend, and I know I've done this successfully before. Can you please help me figure out what I'm doing wrong?

main.tar.gz is a backup of reseller (main) on the old server.

I created the reseller main on the new server, but of course the UID and GID are different.

Both servers are running gnu-tar, though different versions, and they seem fully compatible when I do manual extracts.

In the past when I've done this I've just recreated the reseller on the new machine and then restored the backup. But it's not working :(.

So then I took what I thought was the advice you gave me in an email:

I tried extracting the user main first, but I get errors doing that.

I guess I'm doing something wrong but I can't figure out what.

Please help.

Thanks.

Jeff
 
Jeff.. I believe I had already sent you an email about it...
From what I remember the main.tar.gz is only a file with a list of user.tar.gz files inside it. It wasn't a DA backup. You'd need to extract it manually first, put the user.tar.gz backups into their correct restore location, and then restore normally through DA. Send me another email if I'm missing something.

John
 
A thousand pardons John. I'm blushing with shame and I'm sorry I bothered you and the forum with this issue.

What happened was I had tarred up over five gigabytes of backups to move to the new server, and left the tar to transfer.

When I returned to the job a day later I'd forgotten that I'd created a tarball and proceeded to move my tarball to the user_backups directory and attempt to untar it.

So of course it didn't work :(.

Now that I've untarred my tarball and restored the resulting backup files to the user_backups directory, everything has worked fine.

Thanks for the great help.

Jeff
 
Had the same issue.

Managed to resolve it by changing the symlink from pointing to bsdtar to the one that points to gtar on my freebsd machine.

Although would be good to be able to add additional options to a DA command line which uses tar, as this error can be worked around easily


GNU tar is broken. POSIX specifically allows for vendor extensions (such
as the SCHILY.* extensions which were introduced by star), and the correct
way to handle them is by printing a warning message, ignoring the extension,
and not treating it as an error.

You can work around gtar's breakage by explicitly telling it to ignore these
options via --pax-option="delete=SCHILY.*"

source: http://www.mail-archive.com/[email protected]/msg89138.html
 
You must log in or register to reply here.
Back
Top