root@test8:/>gunzip < /config1/bkp_15_6_16_oraapp.tgz | /opt/freeware/bin/tar xvf -
/opt/freeware/bin/tar: This does not look like a tar archive
/opt/freeware/bin/tar: Skipping to next header
/opt/freeware/bin/tar: Archive contains obsolescent base-64 headers
(break CTRL+C)
root@test8:/>/opt/freeware/bin/tar --version
tar (GNU tar) 1.14
Native AIX unTar error
root@test8:/config1>gunzip < /config1/bkp_15_6_16_oraapp.tgz | tar xvf -
tar: 0511-169 A directory checksum error on media; 804399264 not equal to 13879.
If I tar using native AIX tar and untar it using Native AIX tar it works fine, however, if I use GNU Tar to tar it and GNU Tar to untar it, it fails. The reason for using GNU Tar is getting files larger than 2GB
What could be the problem / issue ?
Note:
File is not corrupt
FTP was in binary mode
ulimit size is -1
works if I use native AIX tar and native AIX untar but fails if I use GNU tar.
Taking the other threads you opened into account which all seem to pertain to the same problem it is quite clear: your system is - for unknown reasons (probably some problem during package installation, but not enough data to verify that) - missing some of the shared libraries the GNU-tar binary relies on. This is why it can't do what it is supposed to do and this is why it can't process your tar-file.
It works like this: GNU-tar calls upon a function "somefunction()", but doesn't contain the code for it. Instead it relies on this code being stored somewhere else on the system (a so-called "shared library", because such files usually contain not only the code for this one but for many such functions). The normal proceedings would now be for tar to load the code representing this function from the library and then execute it. But somehow, in your case, it can't - and because this "somefunction()" is vital to the function of tar - it doesn't get done anything.
So far the general analysis of your problem. Now we need to find out what exactly is holding tar from loading the code for the function from the shared lib. There are several possible reasons:
1 - tar doesn't know where the lib is: any program is guided to the place where it can find the libraries it needs by the variable "LIBPATH" and/or "LD_LIBRARY_PATH". The format is the same as the PATH variable: a list of directories separated by a colon: /some/dir1:/some/dir2:.... .
2 - tar can't read the library: maybe the user tar is started with isn't allowed to read the library - check and make sure the "r"-flag is set for world for shared libraries.
3 - The library is really missing: in this case you need to install it somehow. tar itself doesn't care how the library gets there, so install a package or even just copy the file (for test purposes! You don't want that to be a lasting state.) All this means you have to find out which libaries are missing.
Using tar on different systems, or different point revisions of tar from the same vendor, or different versions completely (eg, Sun vs GNU) do not guarantee compatibility.
Generally, you can create a tar archive on one system which, when transferred to another system, might not unpack. The thing to do is that if you cannot extract an archive using a specific tar utility, try another one.
on the same machine where i made backup and when i tried to restore on the same machine i got this error
root@cloapp1:/pcloneapp>/opt/freeware/bin/tar xvzf pclo_cloapp1_18_6_16_oraapp.tgz
/opt/freeware/bin/tar: This does not look like a tar archive
/opt/freeware/bin/tar: Skipping to next header
/opt/freeware/bin/tar: Archive contains obsolescent base-64 headers
My guess, is that since the this DISK is coming from IBM SAN Storage and the cache battery is dead, and I enabled "Enable Write Caching without Batteries" is the reason for above data corruption ?
I am not sure but investigating further.
agent.kgb, thanks for the z option with gnu tar
---------- Post updated at 06:28 AM ---------- Previous update was at 06:00 AM ----------
agent.kgb,
how would you combine gnu tar -z or -Z (compression) backup and restore with tee command ?