Summary: remote vrestore takes forever

From: Xu, Ying <Ying.Xu_at_telecheck.com>
Date: Thu, 24 Feb 2000 17:18:38 -0600

Special thanks to:

alan_at_nabeth.cxo.dec.com
Brian C. Parkhurst
Udo de Boer

Alan's email gave a very nice summary to my questions. which is:

        Define forever. If it is as long as it takes to read the
        entire tape including the associated network traffic, then
        I'm not especially surprised.

        I believe that vdump is like dump in that it writes a
        directory of the tape's contents at the beginning. However,
        the vrestore may have to wait for the remote dd(1) to
        finish before it can print the directory. Since the
        remote dd(1) doesn't know one block from the next it
        probably has to read the entire tape.

        I'm not sure this is the case, but it wouldn't surprise
        me.

        As for a better way, I wouldn't use the interactive feature
        as a check, but simply write the directory to a file that you
        can review later. By having dd(1) read the entire tape, you
        ensure the tape is readable. That, by itself, is a pretty good
        sign that the backup is good. Running the directory through
        vrestore ensures that vrestore at least recognizes the structure
        of the data on the tape. So, change the 'i' to a 't' and
        redirect the output to a file. The other easy to improve
        the test is to run vrestore on the host with the tape to
        limit the network I/O. In this case, since vrestore is
        reading the tape directly, it will only read what it needs
        (which only verifies the directory).


I didn't have patience to wait 'ls' to finish, but I think Alan is right.
vrestore may have to wait for the remote dd to finish, because 'dd' is an
active process on the remote machine when 'ls' is hanging.

Run vrestore on the machine with tape drive is an easy way to check.
However, I did vdump to a tape drive attached to a HP box, I was unable to
use 'restore -i' to check the file system. It gave me "Tape block size
(32120) is not a multiple of dump block size (1024)" then abort the restore.

My original message is:

--------------------------------
HI, Managers,

I backed up a file system remotely using:

vdump -0uv -b 20 -f - /usr | rsh XXX dd of=/dev/nrmt0h bs=60k

vdump worked fine.

After dump, I tried to verify that I backed up all the files, using:

rsh XXX dd if=/dev/nrmt0h bs=60k | vrestore -if -

it shows:

vrestore: Date of the vdump save-set: Thu Feb 24 13:47:50 2000
(/)

But, when I typed 'ls' after (/), it took forever to give me the list of
files. My questions are:

1. Is it the normal behavior of remote vrestore?
2. Is there a better way to do that?

Thanks

Ying Xu
ITSS - System Management
email:ying.xu_at_telecheck.com
phone: 713-331-6503
Received on Thu Feb 24 2000 - 23:19:28 NZDT

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:40 NZDT