Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 27 Apr 2003 01:45:13 +0300
From:      Tomi Vainio - Sun Finland <Tomi.Vainio@Sun.COM>
To:        obrien@freebsd.org
Cc:        freebsd-current@freebsd.org
Subject:   Re: dump restore problem
Message-ID:  <16043.3065.953470.875344@ultrahot.finland.sun.com>
In-Reply-To: <20030426220959.GA55118@dragon.nuxi.com>
References:  <16042.64964.345642.224980@ultrahot.finland.sun.com> <20030426220959.GA55118@dragon.nuxi.com>

next in thread | previous in thread | raw e-mail | index | archive | help
David O'Brien writes:
 > On Sun, Apr 27, 2003 at 12:44:36AM +0300, Tomi Vainio - Sun Finland wrote:
 > > During my ufs2 migration I've used piped dump restore procedure.  Is
 > > it normal that block sizes like 512 or 1000 don't work?  Block size
 > > 512 gives an error and 1000 hangs forever while 126 is working fine.
 > > 
 > > dump 0buf 512 - / | restore xbf 512 -
 > 
 > dump 0abuf 512 - / | restore xf -
 > 
 > Add -a (infinate tape lenght), and let restore figure out the block size.

cat:/mnt/tmp(132)# dump 0abuf 512 - / | restore xf -
  DUMP: WARNING: should use -L when dumping live filesystems!
  DUMP: Date of this level 0 dump: Sun Apr 27 01:44:12 2003
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/da0s1a (/) to standard output
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 236472 tape blocks.
  DUMP: dumping (Pass III) [directories]
  DUMP: master/slave protocol botched.
  DUMP: The ENTIRE dump is aborted.
Tape is not a dump tape



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16043.3065.953470.875344>