Hi all,

I am having a slightly brain dead moment with a problem I have seen before but the cause escapes me...

When running a savevg command on an AIX 6.1 lpar despite the actual volume group have several thousand files within its associated LV's the savevg backs up successfully, but it only backs up 6 files, namely the vgdata files and NOTHING else, what am I missing here...?

Here is the output from the savevg command I am using:

# /usr/bin/savevg -i -e -v -X -f /export/backup/oradbvg.20120502_114145 oradbvg

Creating information file for volume group oradbvg.

Creating list of files to back up.

Backing up 6 files
Backing up to /export/backup/oradbvg.20120502_114145.
Cluster 51200 bytes (100 blocks).
Volume 1 on /export/backup/oradbvg.20120502_114145
a           12 ./tmp/vgdata/oradbvg/image.info
a          132 ./tmp/vgdata/vgdata.files5178612
a          132 ./tmp/vgdata/vgdata.files
a         3574 ./tmp/vgdata/oradbvg/filesystems
a         3775 ./tmp/vgdata/oradbvg/oradbvg.data
a          494 ./tmp/vgdata/oradbvg/backup.data
The total size is 8119 bytes.
Backup finished on Wed  2 May 11:41:53 2012; there are 100 blocks on 1 volumes.

0512-038 savevg: Backup Completed Successfully.

I have tried this on a number of the volume groups and they all do the same...

Somebody please beat me with a stick and tell me what I am missing here?

Many thanks,

Mike Scheerer

Check your /etc/exclude.oradbvg file and see what's being excluded in there.  If you'd rather have everything backed up, exclude the '-e' flag from your command.

Regards,
Chuck

Hi Chuck,

Thanks, I had already thought of the exclude file and I checked it but also tried without the -e flag and there is no difference to what gets backed up...

I "HAVE" seen this before, but I cannot remember what I did to resolve it.

Perhaps I should point out that the /export/backup is a mounted NFS file system from another AIX lpar, but the savevg command is part of a script that also performs a mksysb prior to the savevg and that works fine. It is only the savevg that has this problem.

Mike

Thanks all, this problem has now been resolved...

The situation in qurestion was due the volume group in question having a number of Vision Solutions Recover NOW protected file systems on it, the mounting of which are handled by the Recover NOW product...