I have a strange/unexpected result when doing system backups on a system.
Its an Alphaserver 4100, Dunix v4.0d + patch kit 3.
The backup is all scripted and seems to work perfectly. I thought I would
just make a few ad hoc comparisons of what's on the tape with what is
actually in the directories - just to run in 'customer confidence mode' as
it were.
Here is an extract of the log:
Dumping filesystem /usr to drive /dev/nrmt0h on tape
---Dump command is: #vdump -0uf /dev/nrmt0h /usr
path : /usr
dev/fset : usr_domain#usr
type : advfs
advfs id : 0x3626f1c2.0008b67d.1
vdump: Date of last level 0 dump: the start of the epoch
vdump: Dumping directories
vdump: Dumping 1062268881 bytes, 1079 directories, 26209 files
vdump: Dumping regular files
vdump: Status at Wed Jul 28 22:07:07 1999
vdump: Dumped 660404651 of 1062268881 bytes; 62.2% completed
vdump: Dumped 705 of 1079 directories; 65.3% completed
vdump: Dumped 12854 of 26209 files; 49.0% completed
vdump: Status at Wed Jul 28 22:10:08 1999
vdump: Dumped 1062268973 of 1062268881 bytes; 100.0% completed
vdump: Dumped 1079 of 1079 directories; 100.0% completed
vdump: Dumped 26209 of 26209 files; 100.0% completed
vdump: Dump completed at Wed Jul 28 22:10:08 1999
Note that the line:
---Dump command is: #vdump -0uf /dev/nrmt0h /usr
is produced by an echo of the command used to do the backup before it
actually runs. Similarly, the line:
Dumping filesystem /usr to drive /dev/nrmt0h on tape
is also produced as part of the script.
So this is a level 0 dump of /usr. The /etc/vdumpdates file confirms this
also:
#cat /etc/vdumpdates
root_domain#root 0 Wed Jul 28 22:00:29 1999
usr_domain#usr 0 Wed Jul 28 22:01:14 1999
Checking what's on the tape:
vrestore -i -f /dev/nrmt0h
vrestore: Date of the vdump save-set: Thu Jul 8 22:01:29 1999
(/) ls
.:
.smdb./ .tags OV/ aaa_this_is_usr
adm advfs/ bin/ ccs/
dict doc/ dt/ examples/
field/ include/ lbin/ lib/
local/ man news opt/
preserve quota.group quota.user sbin/
share/ shlib/ skel/ spool
sys/ tcb/ tmp ucb
users/ var/
(/) cd local
(/local/) cd bin
(/local/bin/) ls
.:
config_save misc_ase_start misc_ase_stop
monitest1_ase_start monitest1_ase_stop os_backup
run_os_backup.sh sudo sudo.old
But looking at the actual contents of the /usr/local/bin directory, we see:
ls -l /usr/local/bin
total 525
-rwxr-xr-x 1 root system 203 Oct 19 1998 config_save
-rwxr--r-- 1 root system 745 Nov 30 1998 misc_ase_start
-rwxr--r-- 1 root system 2253 Nov 30 1998 misc_ase_stop
-rwxr-xr-x 1 root system 1201 Dec 2 1998 monitest1_ase_start
-rwxr-xr-x 1 root system 4219 Dec 2 1998 monitest1_ase_stop
-rwxr-xr-x 1 root system 6066 Jul 28 09:15 os_backup
-rwxr-xr-x 1 root system 3253 Jul 27 17:46 os_backup.270799
-rwxr-xr-x 1 root system 5928 Jul 27 17:46
os_backup.testing_clones
-rwxr-xr-x 1 root system 163 Jan 7 2000 run_os_backup.sh
---s--x--x 1 root system 253952 Jul 7 20:29 sudo
---x--x--x 1 root system 253952 Jul 7 20:29 sudo.old
The vdump archive on the tape is missing some files. Namely the files
os_backup.270799 and os_backup.testing_clones. The files existed prior to
the backup running as you can see from the dates.
I haven't checked any other vdumps to see if any files are missing - I just
checked this at random.
Anybody any idea what's happening here? I checked this yesterday and saw
the same thing. My initial reaction was that the vdump was NOT doing a
level 0 dump. I modified the script to echo the actual vdump command so I
could verify it was doing a level 0.
Thanking you in advance.
Tony
Quotation: "Is the glass half full or half empty?? ...
Well, drink it anyhow, that's what I say".
Pete Goss.
+-----------------------------------------------------------------+
| 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 |
| FAX | 01635-233517 |
+-------------+---------------------------------------------------+
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.
Received on Thu Jul 29 1999 - 08:53:44 NZST