vxdump

[Angela Swyers_1]

Is there a limit to the size of files/filesystems that vxdump can handle?

I have 2 large filesystems that error out:

vxdump: Date of this level 0 dump: Thu Aug 26 02:36:20 2004
vxdump: Date of last level 0 dump: the epoch
vxdump: Dumping /dev/vg12/rlvol3 to /dev/tapen
vxdump: mapping (Pass I) [regular files]
vxdump: mapping (Pass II) [directories]
vxdump: estimated 142092846 blocks (69381.27MB).
vxdump: dumping (Pass III) [directories]
vxdump: dumping (Pass IV) [regular files]
vxdump: 8.31% done, finished in 0:55
vxdump: 15.82% done, finished in 0:53
vxdump: 26.14% done, finished in 0:42
vxdump: 35.03% done, finished in 0:37
vxdump: 43.67% done, finished in 0:32
vxdump: 51.77% done, finished in 0:27
vxdump: 59.86% done, finished in 0:23
vxdump: 68.06% done, finished in 0:18
vxdump: 75.20% done, finished in 0:14
vxdump: Closing /dev/tapen
vxdump: Change Volumes: Mount volume #2
vxdump: fopen on /dev/tty fails: No such device or address
vxdump: The ENTIRE dump is aborted.

[Dave Olker]

Hi Angela,

It looks like vxdump is just saying the tape is full and prompting for another tape. It doesn't appear to be a case where vxdump can't handle the size of the filesystem.

As a test, try directing vxdump to write to a separate filesystem, with sufficient capacity, and see if vxdump completes without error.

Regards,

Dave

[Angela Swyers_1]

You would think that this is the problem except that the script continues on to the next filesystem and backs up data there.

[Dave Olker]

Does the script call unique invocations of vxdump for each filesystem?

[Angela Swyers_1]

yes it does.

[Dave Olker]

Then the failure of one vxdump command shouldn't have any influence on the success or failure of a different vxdump command.

[Angela Swyers_1]

But each one is going to the same tape, so if the tape was really full wouldn't the next vxdump fail too?

[Dave Olker]

Then it sounds like the tape isn't really full, and you're having a problem similar to the one you had with the dump command and HFS filesystems.

Perhaps you need to adjust the settings of the vxdump command to let it know there is more space on the tape. I believe vxdump uses the "-s" option just like dump did. Have you experimented with the -s and -d options?

Dave

[Dave Olker]

Hi Angela,

Did changing the vxdump options allow it to work on these larger directories?

Regards,

Dave

[John Palmer]

vxdump calculates what it thinks is the tape length based as stated above on the -s and -d flags.

The trick is to supply suitably large values for the -s and -d arguments (something like 999999) to ensure that vxdump uses all the available tape. It's also beneficial to supply a large tape blocksize as well (at least 64k) but I can't remember the argument (-b ?). Check the man page.

Bear in mind that vxdump was probably written in the days of open-reel tapes whereas you're probably using an LTO-2 so the defaults are going to be way out. Interestingly, in AIX, backup (which is very similar to vxdump) has been amended to accept the tape capacity in gigabytes,HP take note!

Regards,
John