Attached is a replacement summary to that mailed on the 9/12/98.
I received several useful replies after the original posting.
Thanks to everyone. Merry Christmas.
Regards - Tony
+-----------------------------------------------------------------+
| TONY MILLER - Systems Projects - VODAFONE LTD, Derby House, |
| Newbury Business Park, Newbury, Berkshire. |
+-------------+---------------------------------------------------+
| Phone | 01635-507687(local) |
| Work email | ANTHONY.MILLER_at_VF.VODAFONE.CO.UK |
| X.400 | G=ANTHONY; S=MILLER; C=GB; A=GOLD 400; P=VODAFONE |
| FAX | 01635-506709(local) |
+-------------+---------------------------------------------------+
Disclaimer: Opinions expressed in this mail are my own and do not
reflect the company view unless explicitly stated. The information
is provided on an 'as is' basis and no responsibility is accepted for
any system damage howsoever caused.
At the end of this is essentially what I posted on 9/12/98 regarding
vdump to a remote DLT via vdump & dd. After posing the summary I received
several more replies all of which are noteworthy hence this further
summary posting.
Many thanks to:
Alan.Davis_at_digital.com
This was very helpful but not an option unfortunatly as the tape is not
in a shared bus.
Tob Webster - webster_at_ssdpdc.lgb.cal.boeing.com
Glen - glenn_at_bnd.com.au
W.Flett_at_dcs.rhbnc.ac.uk
----------------------------------------------------------------------------
Wil Flett
Dear Anthony,
Just a thought really. I've been running vdump to remote a DLT drive
for about 6 months without any really performance issues. The main
difference is that we pull the data to the DLT host rather than push it.
To add an extra layer we also we're using secure shell instead of rsh
and things still work OK !
Here a sample command :
ssh fred /sbin/vdump -0 -Cu -b 64 -f - /usr \
| dd bs=64k of=/dev/nrmt0h
This gives a rate to the DLT of about 2Mbs/second over a 10Mb connection.
which is fine for us at present. We do intend to go to 100Mb between
servers as the network appears to be the main bottleneck.
Better reply late than never.
All the best,
-Will
-----------------------------------------------------------------------------
Glen ???
Hi Anthony,
I haven't had any success vdumping to a remote DLT, but I have been able to
do a tar to a remote DLT using GNU tar.
Maybe that is a suitable solution
Cheers Glenn.
-----------------------------------------------------------------------------
Tom Webster
Tony,
> > I'm trying to backup /, /usr etc from the system without the
> > tape to the
> > system with it
> >
> > I'm using the following:
> >
> > vdump -0 -b 60 -f - / | rsh withtape dd of=/dev/nrmt0h bs=60k
> >
> > where withtape is the hostname of the system with the tape.
> >
> >
> > This seems to start off fine but seems to get progressively slower and
> > slower. Its run for about 30 minutes and is only 41% completed. I am
> > seeing about 1mb per minute throughput to the tape:
Sorry, I thought that someone else would mention this: It _MAY_ be a
blocking factor problem. We use TZ88's here wich have a 32k blocking
factor, I think the TZ89's go to a 64k blocking factor (check your
drive documentation). The shrinking performance that you are seeing
may in part be due to trying to adjust for the different blocking
factors when the tape is being written.
As far as the actual data rate: if you are running over 10baseT,
~1.0kb/s is approaching the saturation level for the segment (esp.
if there is anything else on the segment). The theoretical speed
is about 1.2MB/s, but that includes all traffic and protocol headers
and such. You really won't see better speed over the netowork
without compressing the datastream on the remote system.
----------------------------------------------------------------------------
Alan.Davis_at_digital.com
Tony,
Here's another option if you can configure the tape
drive on a shared bus.
[UNIX] HowTo: Set up vdump in a tape service to do local backups on
both members of a TCR/ASE
COMPONENT : TCR 1.5 Tape Service
OPERATING SYSTEM OR PRODUCT NAME : Compaq's Digital UNIX
VERSION : 4.0d
DESCRIPTION OF TASK OR ACTIVITY :
This is the basic procedure on how to set up a shared tape drive in a
TCR 1.5 tape service for local backups with vdump.
HOWTO PERFORM THE DESIRED TASK OR ACTIVITY :
(Step #1)
First go into asemgr and create the tape service
- Just create the service with no ip address and no shared disk
(Step #2)
Create a script that relocates the service to that node and
performs the backup. (one script for each node)
#!/bin/sh
# SCRIPT FOR NODE1
# this assumes there is a tape in the drive
asemgr -m [SERVICE] [NODE]
# since this is the first job we do need to rewind the tape
mt online
mt rewind
vdump -0N /
vdump -0N /usr
#you might need the offline on certain drives like the TZ88
#mt offline
exit
#!/bin/sh
# SCRIPT FOR NODE2
# This assumes there is a tape in the drive
asemgr -m [SERVICE] [NODE]
# since this is the second job we do need to skip to the end
mt online
mt rewind
# forward the number of savesets already on the tape
mt fsf 2
vdump -0N /
vdump -0N /usr
mt offline
exit
(Step #3)
Run these scripts by hand from the respective nodes and
time the backups. Once you are sure everything works,
do step 4.
(Step #4)
Set up cron jobs on each node to run the scripts - give the second job
a hour of time after the first backup completes before it starts.
(Step #5)
Once this is all set up, an operator should be able to change the tape
once a day and you can get complete local backups of the system.
PROBLEMS
Some problems you could have would be an I/O error on the second
node - this should be fixed by adding in the 'mt offline'.
Problem with the 'mt offline' is that it might cause the tape
to eject from certain drives.
Another problem would be something that causes the service not to
failover to the other node - you should do logging to look
for problems.
One other problem is that if your machine goes down during a backup
you will lose that backup. (this wouldn't happen with nsr)
If this machine had a changer you would need to add some
MRU commands to load tapes - you could do a lot more with
these scripts if there was a changer.
WHERE THIS WORKS
This procedure has been reproduced on a TZ88 and a TLZ09.
The TLZ09 was in a HSZ as a pass through device - The TZ88
was just on a shared bus.
ACTUAL SCRIPTS
#!/bin/sh
#---------------------
# SCRIPT FOR DONALD
TAPE="/dev/nrmt6h"
asemgr -m TAPETLZ09 donald
mt -f $TAPE online
mt -f $TAPE rewind
# DO NOT REWIND AFTER VDUMP
vdump -0N -f $TAPE /
# DO NOT REWIND AFTER VDUMP
vdump -0N -f $TAPE /usr
# mt -f $TAPE offline
#!/bin/sh
#---------------------
# SCRIPT FOR HAMMER
TAPE="/dev/nrmt6h"
SETS="2"
asemgr -m TAPETLZ09 hammer
mt -f $TAPE online
mt -f $TAPE rewind
mt -f $TAPE fsf $SETS
# DO NOT REWIND AFTER VDUMP
vdump -0N -f $TAPE /
# DO NOT REWIND AFTER VDUMP
vdump -0N -f $TAPE /usr
# This offline might cause the tape to eject
mt -f $TAPE offline
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Original posting on 9/12/98 follows
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I received only one reply from:
Daniel.Monjar_at_orgtek.com
/No solution to your problem but let me mention something that wasn't
/obvious to me until I asked the list. vdump dumps mounted file
/systems, so one way to vdump a remote file system is to mount it via
/NFS on the node with the tape device. It is a lot easier than using
/pipes to rsh and dd.
I ended up aborting the /usr backup as this had been running for over
two hours and was still less than 30% complete!
I followed Daniel's advice and used NFS mounts. I received no comments
on the ccomsub stuff.
Many thanks - Tony Miller
===============================================================
> We have two alphaserver-4100's connected by UTP and by memory channel
> (they are TRUcluster nodes). 1gb memory, 2 x 533 CPU's each.
> One has a
> tl891 with a single TZ89 tape connected locally. The other does not
> have a tape.
>
> I'm trying to backup /, /usr etc from the system without the
> tape to the
> system with it
>
> I'm using the following:
>
> vdump -0 -b 60 -f - / | rsh withtape dd of=/dev/nrmt0h bs=60k
>
> where withtape is the hostname of the system with the tape.
>
>
> This seems to start off fine but seems to get progressively slower and
> slower. Its run for about 30 minutes and is only 41% completed. I am
> seeing about 1mb per minute throughput to the tape:
>
> #vdump -0 -b 60 -f - / | rsh montst1 dd of=/dev/nrmt0h bs=60
> path : /
> dev/fset : root_domain#root
> type : advfs
> advfs id : 0x3626f1bc.000e7f04.1
> vdump: Date of last level 0 dump: the start of the epoch
> vdump: Dumping directories
> vdump: Dumping 97897754 bytes, 182 directories, 2223 files
> vdump: Dumping regular files
>
> vdump: Status at Tue Dec 8 10:12:57 1998
> vdump: Dumped 6663249 of 97897754 bytes; 6.8% completed
> vdump: Dumped 74 of 182 directories; 40.7% completed
> vdump: Dumped 1273 of 2223 files; 57.3% completed
>
>
> vdump: Status at Tue Dec 8 10:39:09 1998
> vdump: Dumped 40997904 of 97897754 bytes; 41.9% completed
> vdump: Dumped 121 of 182 directories; 66.5% completed
> vdump: Dumped 1970 of 2223 files; 88.6% completed
>
>
>
> Theres nothing in the syslog.log or daemon.log to indicate
> any problems.
>
> I do see the following displayed over and over again on the
> console and
> in the kern.log file though:
>
> rmerror_int: caller = 0xfffffc00005da51c, phys_rail = 0, error_type =
> 0x20000000
> rmerror_int: Error_count = 98 phys_rail = 0 Err_reg =
> 0x20000000 Node =
> 0, lbol7
> ccomsub: state change: run 84 new 99 fixed 98 cpu 1
> ccomsub: state change detected by this node via callback
> ccomsub: state change detected via remote node 1
> ccomsub: state change: end 84 new 99 fixed 99 cpu 1
> rmerror_int: caller = 0xfffffc00005da51c, phys_rail = 0, error_type =
> 0x20000000
> rmerror_int: Error_count = 99 phys_rail = 0 Err_reg =
> 0x20000000 Node =
> 0, lbol7
> ccomsub: state change: run 85 new 100 fixed 99 cpu 1
> ccomsub: state change detected by this node via callback
> ccomsub: state change detected via remote node 1
> ccomsub: state change: end 85 new 100 fixed 100 cpu 1
>
> I dont know if this relates to the problem or if just coincidental (I
> would like to know if this represents a problem though).
>
> pmgr shows the 'dd' process at the top of the list and using 16% - 353
> cpu seconds and increasing. It seems to spend longer and longer in a
> wait state though.
>
> pmgr shows between 15 & 20 tcp segments received and this stays pretty
> constant.
>
> A vdump backup of / to a local TL891/TZ89 on withtape takes
> less than 5
> minutes to complete. Running at in excess of 10mb second throughput >
to the tape. I've still got to do /usr and I need to know why
> this is running so slowly.
====================================================================
Received on Thu Dec 24 1998 - 08:47:54 NZDT