cant restore files to systems with different file system extents.

[marvin51796]

I am not sure where to post this, but i wanted to run this by everyone. We are trying to do a restore from a backup . Now we are going from one machine to another, the issue we have is that we cant restore files that were backed up on a system with 16M extents to a sytems with 32M extents. We have determined that this is due to the tar file that symantec is using.

I was wondering if any has seen this problem before.

thanks

[Patrick Wallek]

That makes absolutely no sense.  The PE Size is at the LVM level and should have absolutely nothing to do with backups or restores.  I am almost certain that I have moved files across systems with different PE sizes and never had any problems.

What is the error you are receiving?  How did you determine that the problem is related to the tar file and an extent size?

[Bill Hassell]

Patrick is quite right, there is no relationship between files and physical extents (PE). The PE szie size is only a bookeeping feature of the volume manager. LVM simply abstracts (virtualizes) storage and the filesystem never sees LVM extents. The VxFS filesystem has it's own extent management but this is not visible to the tar program.

One thing that is missing from your description of the problem is the actual error message from tar. I will take a guess that the error is a block size error. This error has nothing to do with files, filesystems or LVM. The HP-UX tar program is quite archaic and can only understand 10K tape records. Modern tar (gtar for instance) programs and the HP-UX pax program will read other block sizes without a problem. Use pax to restore your files onto the HP-UX filesystems.

[marvin51796]

OK my fault for not explaining this enough, we are using netbackup, we have proved that they standard HP-UX tar works fine, but using the netbackup program file /usr/netbackup/bin/tar doesnt work when the extents don't match. Symantec is working on this but have no reason or fix currently.

What happens when you execute the restore from netbackup is that it hits 2G and the backup crashes. If you run it manually it creates a 0 byte file and crashes. There are no messages or error codes show. We have sent logs out to Symantec with nothing yet.

[Ken Grabowski]

2G is a very telling point of failure.  HP-UX still limits file sizes to a 2GB max unless the file system was created with the -o largefiles flag.  Did you do that? Can you create or copy a file larger than 2GB into the file systems?

[marvin51796]

Yes we have multiple 60G + files on these file systems, its just the restore from netbackup, using their tar binary that isnt working.

[Dennis Handly]

>it's just the restore from netbackup, using their tar binary that isn't working.

Have you tried using gtar or pax on the archive?

(A foreign devil tar that can't handle > 2 Gb seems pretty useless.)

[Ken Grabowski]

Then I guess that wasn't so simple.  But as a few other posters has explained the PE size is not viewable to file handlers, so its doubtful that that has anything to do with it. Probably more coincidental than symptomatic!  So what else do these file systems have in common? 

An old boss once told me that "if it more than 5 minutes to fix its something stupid".  Or in other words look for other things that could be causing the problem. Is there actually more than 2GB in free file space.  Could the netbackup program be using /tmp /var/tmp or something like for expansion of compressed files and is there enough free space there, etc, etc.

I've used netbackup before on HP-UX and never had issues with it.  That was about 5 years ago, so maybe there is a new issue with a new release. But if its not a brand new software release, then I would have expected it to be a know issue. Recovering larger than 2 GB files is a common practice these days.

[marvin51796]

the file systems excluding extent sizes are named the same, setup the same, same folder structure. They are on he same SAN, same type of drives, same speed of drives.

we are trying to setup a new epic environment, so we are taking a backup of the production stuff, trying to restore the data on another server with the same directory structure.

I have also extracted the tar binary from older netbackup clients and have the exact same problem. I have also tried doing my own tar creation and extraction, without full blown netbackup, but the netbackup tar binary, and have the exact same results, 0 byte tar files.

[Dennis Handly]

>but the netbackup tar binary, and have the exact same results, 0 byte tar files.

If you have tusc, you can actually see what error is causing the problem and how the file is opened.