Xref: utzoo comp.unix.misc:797 comp.unix.admin:776
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!tektronix!sequent!edw
From: edw@sequent.UUCP (Ed Wright)
Newsgroups: comp.unix.misc,comp.unix.admin
Subject: Re: backup difficulties
Message-ID: <49965@sequent.UUCP>
Date: 8 Jan 91 18:18:44 GMT
References: <SHAWN.91Jan7121818@litsun8.epfl.edu> <1769@cluster.cs.su.oz.au>
Reply-To: edw@sequent.UUCP (Ed Wright)
Distribution: comp
Organization: Orygun Society For HUman Rustabillity Assessment
Lines: 28

In article <1769@cluster.cs.su.oz.au> yar@cluster.cs.su.oz (Ray Loyzaga) writes:
%In article <SHAWN.91Jan7121818@litsun8.epfl.edu> shawn@litsun.epfl.ch writes:
%> 
%>   DUMP: Date of this level 9 dump: Mon Jan  7 12:00:02 1991
%>   DUMP: Date of last level 0 dump: the epoch
                                      ^^^^^^^^^
	Sounds like you are using the dump option to update the file
	/etc/dumpdates (no biggie)
%>   DUMP: Dumping /u/giraud to /dev/rst8
%>   DUMP: bad sblock magic number
	Did you clean the filesystem before you tried to dump it ?
	Try unmounting the filesystem and then run fsck -p on the
	raw device.
	If it turn up that you do in fact have a bad superblock
	you will need to run fsck manually specifying an alternate
	superblock address. Check the man page and the article(s) in
	vol 2.
	Then do  your dump. (on the unmounted filesystem) 
	That should help things out
%>   DUMP: The ENTIRE dump is aborted.
%> 
Hope that helps
Ed
-- 
	Without American Veterans
				There would be no America 
							Or American Freedoms
edw@sequent.COM  anybackbone!sequent!edw