Summary: ufsdump changing volumes on pipe input

Thanks for the replies. 
"Ken Robson" <ken@tv2die4.com>
Tom Crummey <tom@ee.ucl.ac.uk>
Mike Kiernan <mkiernan@onet.pl>
"Cian O'Sullivan" <cian@parthus.com>
"Ben Green" <awk@carolina.rr.com>

Suggestions included

1) If you have MU4 applied look at the fssnap command
We don't have fssnap installed, but I might follow this up later.

2) It thinks it's running out of tape. Give ufsdump some parameters to tell
   it not to calculate the tape length. The man page has the details.
I don't think this is relavant to our problem (no tape involved)

3) I've seen before people use disksuite:
   lockfs
   metattach spare to real
   metadetach
   something like that...

4) Try dumping directories one at a time, instead of doing whole file system
   Or try , /usr/sbin/ufsdump 0f - . | (cd /spare_root;ufsrestore xvf - )
   Or maybe try cpio

5) Try cd /spare_root;/usr/sbin/ufsdump 0f - /dev/dsk/c0t0d0s0 | ufsrestore xf -
   Or perhaps ufsrestore rf -

In the end, my script started majically working again!!!!!!
I attribute this to the fact that ufsdumping a live file
system is not really a good idea - I appears perhaps
sometimes it works and sometimes not.

david


Original message.
> 
> iHi,
>      I'm trying to make a hot backup of our root disk. I've done this
> many times in the past on various machines and it seemed to work fine.
> Part of the script is ufsdumping the filesystems using:
> /usr/sbin/ufsdump 0f -  /dev/dsk/c0t0d0s0 | (cd /spare_root;ufsrestore
> xf -)
> 
> This last time I did this I got the following error:
> changing volumes on pipe input
> abort? [yn] y
> dump core? [yn] n
> 
> I have updated the recommended patches on the machine since I last ran
> this
> command. We are now running
> 5.8 Generic_108528-08 sun4u sparc SUNW,Ultra-250   
> But we run the same recommended patches on an E450 and it seems OK.
> All files systems are local:
> Filesystem            kbytes    used   avail capacity  Mounted on
> /dev/dsk/c0t0d0s0    3009594 2561417  387986    87%    /
> /dev/dsk/c0t8d0s0    3009594 2562056  387347    87%    /spare_root
> 
> I know that ufsdump is not recommended on a live system, but I don't
> want to
> take it down for this. Also I don't want a real time mirror since part
> of the purpose
> of the /spare_root is for emergency reboots should any upgrade cause
> problems
> with the root directory.
> 
> Any Ideas what might be causing this? Or perhaps a better way to
> duplicate
> the root disk on demand?
> 
> Thanks
> David
> 
> 
>