can't restore verified mksysb image
Dariusz Dej
Hi,
I'd like to restore rootvg from mksysb image on replaced disk.
The system backed-up used four disks:
hdisk0 + hdisk1 for rootvg
hdisk3 + hdisk4 for secondvg
mksysb backup tape was verified using `smit lsmksysb' method.
Now, when restoring:
I can boot from tape
I choose to use new disk for restoration (only one this time, but 36GB)
I start restoring and after steps, that create volumes and filesystems,
when actual restoration begins I get:
READ ERROR: I/O error
assuming zeros and continuing
- these two lines scroll numerous times and in the end I get:
Update_Status[80]: no space 6% of mksysb restored
I tried other backup tape (also verified by listing files) with the same
result.
I/O error message seems to be related to block size problem rather than to
media error, am I right?
In the hope I can force different block size I went to shell prompt
(`Access Advanced Maintenance Functions') after booting from tape,
but tools on the RAM disk seem to be incomplete: no `chdev', `tctl'
looks unsuccessfully for `lsattr'.
The only thing I was able to see was the content /tapeblksz (on RAM disk
so probably taken from second mksysb file), that looked quite resonably
512 NONE.
Maybe this is important: mksysb images were created, verified and tried to
be restored on HP C1554A (C1537A) tape drive installed as `Other SCSI tape'.
Any suggestions to solve the problem are welcome.
Thanks in advance,
Darek
PS. Does the amount of RAM matter during restoration?
I removed some memory DIMMs to make POST time shorter.
--
Dariusz Dej
System Manager at Institute of Automatics
UMM Cracow, Poland
Scanlon J
two 4.5 gig drives in the rootvg volume group to one 9 gig rootvg disk. When I
added a second 9 gig drive it restored just fine.
Hope this helps,
Jim Scanlon
Joe Ryals
example hdisk0 was the failed disk and was a 9.1 GB disk and was set at the
default value of 16 MB PP size, then you will have a problem trying to restore a
mksysb tape to a disk that requires a larger PP size (64 MB). I am not sure how
you would get around this, but is probably the problem you are seeing.
Joe Ryals
Joerg Bruehe
Dariusz Dej wrote:
>
> [...]
> mksysb backup tape was verified using `smit lsmksysb' method.
>
> Now, when restoring:
> I can boot from tape
> I choose to use new disk for restoration (only one this time, but 36GB)
> I start restoring and after steps, that create volumes and filesystems,
> when actual restoration begins I get:
>
> READ ERROR: I/O error
> assuming zeros and continuing
Your booting from tape uses only the "boot image" close to the
start, not the files saved in the later parts.
AFAIK, the file save in a "mksysb" tape ("backup by name" ?)
has the drawback that all file information is in the beginning
and all file data only after that. The consequence is that
if the tape is damaged some distance from the start,
you can still list the contents and will encounter errors in
the data only - so the "verification" does not cover the data part.
This speeds up a contents listing (good), but the lack of a true
verification makes it a badly designed format, IMHO.
>
> [...]
> Maybe this is important: mksysb images were created, verified and tried to
> be restored on HP C1554A (C1537A) tape drive installed as `Other SCSI tape'.
Sorry for the bad tidings, but I have read several reports of
bad experiences with the 4mm DAT tapes. One problem seems to be
a (slow) disadjustment of the read/write head (drum) relative
to the tape path - recently written tapes might be readable
while older ones will fail.
Your problem, however, might be different.
Still, you might try to read the tape on another drive, use
dd if=/dev/norewind_raw_tape_name of=/dev/null bs=...
repeatedly, but I do not know the block size.
If that shows no read errors, it means your problems are specific
to the drive connected to the RS/6k, so you might connect the
other drive to the RS/6k and try again.
Remember that these HP drives have DIP switches at the bottom
which need to be set specific to the platform.
My consequence is to avoid this technology, if possible -
even in spite of its low cost, the reliability seems too bad,
and my experiments with drivesd that worked on a Tru64 machine
and failed on a Linux PC were very disappointing.
Hope you get it solved somehow,
Joerg Bruehe
--
Joerg Bruehe, SQL Datenbanksysteme GmbH, Berlin, Germany
(speaking only for himself)
mailto: jo...@sql.de
Ulrich Koerner
Maybe you had mirrored your rootvg or something like this.
The solution would be to supply a special disk which contains
corrected *.data files. You can extract these from tape (on another
system):
# chdev -l rmtX -a block_size=512
# tctl -f /dev/rmtx rewind
# mkdir /tmp/disk
# cd /tmp/disk
# restore -s2 -xvqf /dev/rmtx.1 ./bosinst.data ./image.data
# echo data > signature
Then you have to edit bosinst.data and image.data. Remove all entries
pointing to a second harddrive. Look for the shrink line in image.data
and set it to "SHRINK=yes", look for the COPY lines in the lv stanzas
and set them to "COPY=1", set all PP to the values of LPs
# find . -print | backup -ivqf/dev/rfd0
This will create a supplemental disk for your cloning installation. It
will be read before installation starts up.
Regards - Ulrich
Joe Ryals <jry...@mediaone.net> wrote in message news:<3B8DA17E...@mediaone.net>...
Dariusz Dej
> Hi!
>
> Dariusz Dej wrote:
> >
> > [...]
> > mksysb backup tape was verified using `smit lsmksysb' method.
> >
> > Now, when restoring:
> > I can boot from tape
> > I choose to use new disk for restoration (only one this time, but 36GB)
> > I start restoring and after steps, that create volumes and filesystems,
> > when actual restoration begins I get:
> >
> > READ ERROR: I/O error
> > assuming zeros and continuing
>
[...]
> AFAIK, the file save in a "mksysb" tape ("backup by name" ?)
> has the drawback that all file information is in the beginning
> and all file data only after that. The consequence is that
> if the tape is damaged some distance from the start,
> you can still list the contents and will encounter errors in
> the data only - so the "verification" does not cover the data part.
>
> This speeds up a contents listing (good), but the lack of a true
> verification makes it a badly designed format, IMHO.
I can tell two things on this:
1. IBM fax suggests `lsmksysb' test to see if "the tape is readable",
what of course doesn't mean, that _all_ tape is readable. :-)
2. Would I get `READ ERROR: I/O error' if the tape was not readable
or rather something like `READ ERROR: media error'?
>
> >
> > [...]
> > Maybe this is important: mksysb images were created, verified and tried to
> > be restored on HP C1554A (C1537A) tape drive installed as `Other SCSI tape'.
>
> Sorry for the bad tidings, but I have read several reports of
> bad experiences with the 4mm DAT tapes. One problem seems to be
> a (slow) disadjustment of the read/write head (drum) relative
> to the tape path - recently written tapes might be readable
> while older ones will fail.
>
> Your problem, however, might be different.
The mksysb tape is about one month old, so head drifting is rather improbable
in my opinion.
Thanks,
Darek
Dariusz Dej
> Hi,
>
> I'd like to restore rootvg from mksysb image on replaced disk.
>
> The system backed-up used four disks:
> hdisk0 + hdisk1 for rootvg
The follow-ups I've got gave me new keywords to search in the group and
now I can see that moving to bigger disk (planned or when disaster strikes)
created quite a big problem for many people.
However, I must admit, that the more I read the less I know:
Should AIX 4.3.2 mksysb image create valid lv's automatically or not?
(yes, I'm on AIX 4.3.2, what I've forgotten to mention before)
Following people, that suggested updating image.data on similar problems
I edited image.data extracted from tape and I created signatured diskette.
Restoration process looked a bit different now and I progressed to 29%
instead of 6% in the first attempt, but after this I/O error messages
appeared again. :-(
I'd like to know what are the minimal changes that I need to apply to
image.data file?
Is it enough to update only vg and lv stanzas and to left fs stanzas untouched?
Is it possible to "divide" the process of restoration into steps, that can
be executed "by hand" from RAMdisk? This could help to understand what exacly
fails... If yes, what are these steps or maybe whole restoration is done
by script hidden in some RAMdisk directory?
Any advice is greatly appreciated.
Thanks in advance,
Darek
Joerg Bruehe
Dariusz Dej wrote:
>
> Joerg Bruehe <jo...@sql.de> wrote in message news:<3B8E1B27...@sql.de>...
>
> [...]
>
> > AFAIK, the file save in a "mksysb" tape ("backup by name" ?)
> > has the drawback that all file information is in the beginning
> > and all file data only after that. The consequence is that
> > if the tape is damaged some distance from the start,
> > you can still list the contents and will encounter errors in
> > the data only - so the "verification" does not cover the data part.
> >
> > This speeds up a contents listing (good), but the lack of a true
> > verification makes it a badly designed format, IMHO.
>
> I can tell two things on this:
> 1. IBM fax suggests `lsmksysb' test to see if "the tape is readable",
> what of course doesn't mean, that _all_ tape is readable. :-)
Exactly. IMNSHO, this is a design problem of the format and/or the
restore tool - it should offer an option "list contents and check
everything until the end".
If the file headers and the file data were intermixed all along the
tape (like in 'tar' or 'cpio'), this would happen implicitly.
I propose you try 'dd' just to check readability / I/O errors.
> 2. Would I get `READ ERROR: I/O error' if the tape was not readable
> or rather something like `READ ERROR: media error'?
I assume, the former.
'I/O error' is the text used for the error code 'EIO' (errno == 5),
so the 'perror' routine would just deliver that text.
AFAIK, no Unix system does tell whether this is due to defective
media, defective drive electronics, power failure (for an external
drive), sudden cable cut, ...
How should the application software tell it is the media?
>
> >
> > [...]
>
> The mksysb tape is about one month old, so head drifting is rather improbable
> in my opinion.
Sounds like. Also, head drifting should have shown up from the
beginning of the tape, so booting should have failed already.
That is why I wrote "Your problem, however, might be different."
Sorry I have no better tips,
Arshad
why don't you install the rootvg via CD's on those four disks, then
fsf 3 /dev/rmt0 and then
restore -xvqf /dev/rmt0
Its not transparent but may be it will work.
Make the tape block size to 0 before restoring the tape.
Arshad
In article <df997bb1.01083...@posting.google.com>,
da...@ia.agh.edu.pl says...