SUMMARY: DUMP vs VDUMP

From: Rick Beebe <BEEBE_at_BIOMED.MED.YALE.EDU>
Date: Fri, 05 May 1995 08:51:39 -0400 (EDT)

My original message (which I didn't save a copy of. Sheesh!) told of
switching from dump to vdump. Vdump consistently failed partway through the
backup. I asked if this was known problem and why vdump was better than
dump anyway.

Many thanks to those who responded:

--------------------------------------------------------------------------

From: " Andrew T. Lloyd " <atlloyd_at_acer.gen.tcd.ie>

One problem with dump, is that if it is run from a cron controlled
script, and there is a failure of dump (such as forgetting to put
a tape in!) then cron dies. This is a reboot problem. Otherwise
dump has been doing us fine for a year. If it works *good enough*
why switch ?

--------------------------------------------------------------------------

From: jacy_at_fluid.mro.dec.com

  There is a bug with vdump on V3.0... Upgrading to V3.1 will fix it, or you
could apply the patch....

--------------------------------------------------------------------------

From: Hellebo Knut <bgk1142_at_bggfu2.nho.hydro.com>

Get patches for vdump/dump/vrestore/restore on www.service.digital.com or
ftp.digital.com.

--------------------------------------------------------------------------

(me again...)
I've decided for now that dump is working well enough. We'll be upgrading
to OSF/1 3.2a shortly and I'll revisit the whole issue then.

I also asked for the steps involved in switching form UFS to AdvFS. I
received the following:

--------------------------------------------------------------------------

From: jacy_at_fluid.mro.dec.com

 Converting to ADVFS will require a free disk....

        EXAMPLE for moving /usr from UFS to ADVFS.......

mkfdmn /dev/rz1c usr_domain (OR ANY NAME YOU WISH)

mkfset usr_domain usr

mount -t advfs usr_domain#usr /mnt

  The following example taken from the vrestore man page.......

vdump -0f - /usr | vrestore -xf - -D /mnt

        Make the necessary changes to /etc/fstab

usr_domain#usr /usr advfs rw 0 0

        And you're all set....

        You may want to install the ADVFS Utilities (If you have the license)
        Those subsets allows binding of 2 or more disks....

--------------------------------------------------------------------------

From: Torbj|rn Lindgren <tl_at_ae.chalmers.se>

Well, if you have extra diskspace it's easy (it isn't much harder
without it if you have a fast tape-backup... Except for / and /usr!).

Short listing:
1. Create the file domain:
    mkfdmn <special> <domain-name>
2. Create the fileset:
    mkfset <domain-name> <set-name>
3. Mount the new fileset:
    mount -t advfs <domain-name>#<set-name> <mount-point>
4. Move the data:
    cd <mount-point>
    vdump -0f <old-mount> | vrestore xf -
5. Modify /etc/fstab so that the new fileset is mounted instead of the
old filesystem.

Repeat 2-5 for each additional file-set you want in the domain. If you
want more than one disk and have 'Advanced Filesystem Utilities', add
more disks using 'addvol <special> <domain-name>' after point 1. If
you know from the beginning that you will use more than one disk, do
it between point 1 and 2.

Notes:
   <special> is a device-file, for example /dev/rz1c or /dev/rz3h.
   <domain-name> is the name of the new domain (unique in the system).
   <set-name> is the name of the fileset (unique in the domain).
   <mount-point> is a temporary mount-pount, for example /mnt

An example: Moving /usr/local to the new domain 'disk', fileset
'local'. The domain consists of /dev/rz1c.

1. mkfdmn /dev/rz1c disk
2. mkfset disk local
3. mount -t advfs disk#local /mnt
4. cd /mnt
   vdump -0f /usr/local | vrestore xf -

5. Then change the line in /etc/fstab from:
/dev/rz3g /usr/local ufs rw 1 3
   To:
disk#local /usr/local advfs rw

(if you use quota, use 'advfs rq,userquota,groupquota' instead, that's
what I use on one fileset).

--------------------------------------------------------------------------


    _____________________________________________________________________

     Rick Beebe (203) 785-4566
     Data Network Operations
     Biomedical Computing Unit beebe_at_biomed.med.yale.edu
     Yale University School of Medicine beebe_at_yalemed.bitnet
     333 Cedar Street, New Haven, CT 06510
    _____________________________________________________________________
Received on Fri May 05 1995 - 11:23:18 NZST

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