Hi all
Thanks to Eric Bennett, Jon Buchanan, Jim Belonis, Lucien Hercaud,
and boris_at_gore.afep.cornell.edu for their responses to my query
about a problem with rdump. The original message is included at
the end of the summary.
Although none of the suggestions provided a solution to my problem
I summarize them below because several good points were made and
they may be helpful to others.
Two people suggested that the dump had worked and the problem
was with restore but the timings made me believe that the dump
was the problem. I have backed up this file system many times
and the time is always around 25 minutes and rdump gives an
update about every 5 minutes as it goes. This dump took only
8 minutes and jumped from 26 minutes estimated to 3 minutes.
This is not the normal behaviour. That is why I suspected the
dump and not the restore.
I managed to confuse some people with my remark about backing
up the system remotely. I was trying to be brief. What
I meant was that I access the system from a remote login not
from the console. That is why I can't use single user mode.
I know that you can use rdump to back up to a remote tape
device while in single user mode. I do this regularly on two
other machines where I do have access to the console.
One suggestion was to run fsck manually. I did use
"/sbin/ufs_fsck -p" from single user mode and it just reported
that the file system unmounted cleanly as it normally does.
Maybe I should have used the "-o" option to force fsck to check
the file system.
Another suggestion about checking the dump parameters and making
sure the restore parameters correspond is a very good point as I
once found out the hard way but it is not the problem this time.
I use scripts to do the dump and the restore. I have used the
same scripts many times without problems and nothing has been
changed.
Likewise suggestions about checking that the correct device is
being written to and that the tape drive is behaving normally are
good ideas but not the cause of this problem. At the same time I
used the same script and the same tape drive to back up 3 file
systems on 3 different machines for a total of 9 dump images and
only one gave trouble. I can restore from any of the other 8
without problems. I have used this procedure again since and it
is always only this one file system giving trouble.
Jim Belonis pointed out that removing the /etc/dumpdates file
wouldn't make any difference. I guess this is obvious but at that
stage I was willing to try anything.
===================================================================
> I have to back up a machine remotely so I am not able to do
> it from single user mode. I use /etc/nologin to prevent
> users logging in but recently a dump failed because of a user
> writing to disk while the dump was still in progress.
>
> This must have been either from a background job or via an
> NFS mount. Both these are possible with the system in
> multi-user mode.
>
> Now all attempts to back up that disk partition fail - even
> from single user mode. I have rebooted the machine and tried
> again but the same problem occurs.
>
> This is the relevant part of the output:
>
> rdump: Mapping (Pass I) [regular files]
> rdump: Mapping (Pass II) [directories]
> rdump: Estimate: 269395 tape blocks on 0.00 volume(s)
> rdump: Dumping (Pass III) [directories]
> rdump: 0.19% done -- finished in 00:26
> rdump: Dumping (Pass IV) [regular files]
> rdump: 60.89% done -- finished in 00:03
> rdump: Actual: 269403 tape blocks on 1 volume(s)
> rdump: Level 0 dump on Wed Apr 24 08:07:33 1996 EST
> rdump: Dump completed at Wed Apr 24 08:15:55 1996 EST
>
> As you can see rdump claims to have dumped the correct number
> of tape blocks but the time is too short. The estimate of
> 00:26 is about right based on past experience but the actual
> time taken is only about 00:08. In any case rrestore can't
> read the dump image produced so something has gone wrong.
>
> I tried removing the /etc/dumpdates file to erase all record
> of previous dumps but this made no difference.
>
> Does anyone know how to cure this problem?
>
> Thanks in advance for any suggestions.
>
Ian Mortimer
Department of Physics Tel : +61 7 3365 3416
University of Queensland Email: mortimer_at_physics.uq.edu.au
St. Lucia, Brisbane Fax : +61 7 3365 1242
Queensland, Australia. 4072.
Received on Tue Apr 30 1996 - 01:24:52 NZST