I had asked if anyone could shed some light on why files were not being
vrestored, the full question appears below.
I later discovered that many files were in the process of being created on
the old volume while the
vdump was running. I suspect that this was the source of the error I
encountered.
Mary Freesmayer, "Freesmeyer, Mary" <Mary.Freesmeyer_at_LendersService.com>
had some excellent advice, namely to use cpio rather than vdump/vrestore in
the following syntax:
cd /old
find . -print|cpio -pvdum /new
As I later discovered, this had the advantage over vdump/vrestore of
printing a list of the files copied which can be
preserved if run from cron or at.
Thanks and regards,
Bruce
Original Post follows:
On an AS1200 running V4.0d, PK2, I get 208 errors of the following type:
vrestore: can't get path for dir inode <10517>,file <aqdata.txt>
with, of course, the inode numbers and file names being different for each
event.
This occurs when I am trying to move data from a ufs file system within LSM
on an RA7000
to an advfs file system onto a new RA7000 using a vdump/vrestore sequence
as follows:
vdump -0 -f - /old-data | (cd /new-data; vrestore -x -f -)
The command sequence continues to completion with the exception of these
208 error messages.
When I look at the /new-data contents, the files indicated in the error
messages do not exist, though
the directories in which they would appear do exist.
If I look at the /old-data contents, the files all exist and are readable.
The file system on which /old-data exists was mounted cleanly.
The purpose of copying the data is to provide a backup of the original
data, since none exists, so while I can
copy the files from the old file system to the new, it is an incomvenience.
Since there is a total of approximately 700 GB of data in seven file
systems to copy, I am concerned about
why these errors are happening.
If anyone has any suggestions, I would be delighted to hear of an answer,
or even speculation all of which I will summarize.
I know the system is out of date as far as patch-kits are concerned. The
owners of the data are
horrified of losing it (hence the extravagant backup scheme) and refuse to
allow patches to be
installed until the backup of the data is complete.
If there is a known vdump/vrestore issue fixed in post PK2 patches, this
will help me argue for installing the latest PK.
Thanks and regards,
Bruce
Received on Mon Feb 07 2000 - 13:44:45 NZDT