On the 29/7/99, I sent out a request for info regarding some strange vdump
activity whereby level 0 dumps did not seem to be archiving all files
(original posting at the end of this summary).
This is still really weird and I never did get to the bottom of it, except
to say that it has been working fine with no apparent changes for some time
now. I sort of thought there might be a scripting problem, so I added a few
explicit dump commands, not using the coded loop, but otherwise the same.
These produced exactly the same results as the original (comforting at
least) at the time.
I was reading the correct vdump archive, I used a manual rewind of the tape
followed by skipping over the correct number of file sets before doing the
vrestore. Also, we have a company policy whereby we put files named
'aaa_this_is_???' in each root directory to aid checking of such things.
I have included Dr Tom's reply as it might be very helpful to others in my
situation diagnose the error. I did try restoring the archive using the -D
switch onto a new Fileset, and the files in question WERE NOT present.
Doing a vdump of the sub-directory containing the files and a vrestore of
this DID have the file in the archive - they also showed up in the vrestore
interactive listing. The files DEFINITELY were there before the vdumps were
run. Its really odd.
So, its working just fine now - I don't know why it wasn't before and is now
- no system changes that I'm aware of. I'll put it down to user error (my
own).
Once again, many thanks to Dr Tom for a very explicit and helpful reply as
always.
Regards - 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.
I received comments from the following:
Dr. Tom Blinn, 603-884-0646 [tpb_at_doctor.zk3.dec.com]
Degerness, Mandell ITSD:EX [Mandell.Degerness_at_gems2.gov.bc.ca]
==============Degerness,
Mandell===============================================
Sorry if this sounds simplistic, but are you sure you are reading the same
dump file that you wrote? I notice that you are using the non-rewind device
and you did not mention about rewinding the tape prior to performing the
dump or the restore.
Regards,
Mandell Degerness
============================================================================
=====
==============Dr
Tom============================================================
> 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 can see why you believe that, but I don't think you've proven it -- all
you
have proven is that the interactive mode "ls" command isn't displaying names
of those files. That doesn't necessarily mean the data for the files isn't
on
the tape, but if the files are there, there's a bug in the display logic.
Also, the fact that the dates reported on the files pre-date when you think
you ran the backup doesn't prove that the files were present on the disk, in
their current locations, when the dump was run. They could have been in
some
other directory in the same file system hierarchy and been moved into where
they are presently located. You haven't proved that the files were present
in their current locations when the backup was run.
> I haven't checked any other vdumps to see if any files are missing - I
just
> checked this at random.
May I suggest a different approach? Before you do the vdump, run a "find"
on
the file system hierarchy and use the -exec ls -ld {} option to get a list
of
all the files, directories, etc. That will show you what was present in the
file system at the time of the dump (as long as nothing is modifying things
as you do the work). Then, after you've done the dump, set up a disk where
you can restore the whole file system. (If you're really paranoid, use find
to find all the files in the file system and get a checksum on them, as
well,
so that you can verify the contents.) Restore the file system onto your new
scratch disk. Run find using the -exec ls -ld {} option to get a list of
all
of the things that were restored, and if you were paranoid, checksum all of
the files to make sure the restored contents match the dumped contents.
When
you have done this, you'll be able to tell whether you can restore what you
dumped, and whether EVERYTHING you can see in the file system with find was
actually dumped and then restored. This is a VALID test, or as close to one
as you can get (unless you shut the system down to single user mode to do
the
testing, so there is no possibility of anything changing in the file system
as you are dumping it). If you have ACLs on the files, you might also want
to be paranoid about the ACLs and make sure they are dumped and restored,
for
every object that has (or can have) ACLs associated with it.
I've done tests like this from time to time in the past (even though it's
not
my primary job to do this sort of testing). I won't claim there have never
been bugs in vdump and vrestore, but MOST of them have been found and fixed.
So I'm very sceptical that the explanation for what you are seeing is that
the
files were there but not dumped to the backup media.
Tom
============================================================================
===========
=============================original
posting================================
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 Fri Aug 13 1999 - 07:55:49 NZST