Hello,

I have Sun Solaris 8 (2.8) with a SCSI 8mm tape drive that I'm
doing ufsdumps via ssh && dd to other Solaris boxes that works
just fine.

From the tapehost (Box that's has the drive attached)
I issue to dump:

ssh  -l root <remote_host_name_other_sun_box> -n ufsdump 0fu -
<file_system_to_be_dumped>  | dd bs=64k of=/dev/rmt/0n

To get the data back:

mt -f /dev/rmt/0 rew

mt -f /dev/rmt/0 fsf (if I dumped more than one dump to a single
tape....)

Then to restore the data:


dd bs=64k if=/dev/rmt/0n | ufsrestore vibf 64k -

WORKS just fine, speed is great! Like Sliced Bread baby!

Now I want to do the same thing only dump a Redhat 9.0 box
to the Sun box.

This works only for small test dumps, say just /etc or just /var:

From the tapehost (Box that's has the drive attached)
I issue

ssh  -l root <remote_host_linux_box> /sbin/dump -0a -f  - /var | dd
bs=64k of=/dev/rmt/0n

Then to read the tape as usual:

dd bs=64k if=/dev/rmt/0n | ufsrestore vibf 64k -

HOWEVER, when the dump is LARGE i.e say dumping root i.e. "/" I the
dump
is successful but the restore core dumps:

# dd bs=64k if=/dev/rmt/0n | ufsrestore vibf 64k -

Verify volume and initialize maps
Note: doing byte swapping
Dump   date: Tue Jan 06 13:49:05 2004
Dumped from: the epoch
Level 0 dump of / (dir usr) on linuxbox:/dev/hda1
Label: /
Extract directories from tape
Segmentation Fault - core dumped

[ Post a follow-up to this message ]

The Institute of Astronomy is part of the Faculty of Physics and
Chemistry <http://www.ast.cam.ac.uk/physchemfaculty> within the School
of the Physical Sciences
<http://www.cam.ac.uk/cambuniv/schools/physsci/> of The university of
Cambridge <http://www.cam.ac.uk/>

top <http://www.ast.cam.ac.uk/mrtg/#top>  |  home
<http://www.ast.cam.ac.uk/>  |  search
<http://www.ast.cam.ac.uk/search/>  |  comments
<http://www.ast.cam.ac.uk/contact/fo...?contact=webman>  |  help
<http://www.ast.cam.ac.uk/help>  Page last saved: 28th October 2003  by


The Institute of Astronomy is part of the Faculty of Physics and
Chemistry <http://www.ast.cam.ac.uk/physchemfaculty> within the School
of the Physical Sciences
<http://www.cam.ac.uk/cambuniv/schools/physsci/> of The university of
Cambridge <http://www.cam.ac.uk/>

top <http://www.ast.cam.ac.uk/mrtg/#top>  |  home
<http://www.ast.cam.ac.uk/>  |  search
<http://www.ast.cam.ac.uk/search/>  |  comments
<http://www.ast.cam.ac.uk/contact/fo...?contact=webman>  |  help
<http://www.ast.cam.ac.uk/help>  Page last saved: 28th October 2003  by


The Institute of Astronomy is part of the Faculty of Physics and
Chemistry <http://www.ast.cam.ac.uk/physchemfaculty> within the School
of the Physical Sciences
<http://www.cam.ac.uk/cambuniv/schools/physsci/> of The university of
Cambridge <http://www.cam.ac.uk/>

top <http://www.ast.cam.ac.uk/mrtg/#top>  |  home
<http://www.ast.cam.ac.uk/>  |  search
<http://www.ast.cam.ac.uk/search/>  |  comments
<http://www.ast.cam.ac.uk/contact/fo...?contact=webman>  |  help
<http://www.ast.cam.ac.uk/help>  Page last saved: 28th October 2003  by



uzi69mmm@yahoo.com wrote:
quote:

>Hello,
>
>I have Sun Solaris 8 (2.8) with a SCSI 8mm tape drive that I'm
>doing ufsdumps via ssh && dd to other Solaris boxes that works
>just fine.
>
>From the tapehost (Box that's has the drive attached)
>I issue to dump:
>
>ssh  -l root <remote_host_name_other_sun_box> -n ufsdump 0fu -
><file_system_to_be_dumped>  | dd bs=64k of=/dev/rmt/0n
>
>To get the data back:
>
>mt -f /dev/rmt/0 rew
>
>mt -f /dev/rmt/0 fsf (if I dumped more than one dump to a single
>tape....)
>
>Then to restore the data:
>
>
>dd bs=64k if=/dev/rmt/0n | ufsrestore vibf 64k -
>
>WORKS just fine, speed is great! Like Sliced Bread baby!
>
>Now I want to do the same thing only dump a Redhat 9.0 box
>to the Sun box.
>
>This works only for small test dumps, say just /etc or just /var:
>
>From the tapehost (Box that's has the drive attached)
>I issue
>
>ssh  -l root <remote_host_linux_box> /sbin/dump -0a -f  - /var | dd
>bs=64k of=/dev/rmt/0n
>
>Then to read the tape as usual:
>
>dd bs=64k if=/dev/rmt/0n | ufsrestore vibf 64k -
>
>HOWEVER, when the dump is LARGE i.e say dumping root i.e. "/" I the
>dump
>is successful but the restore core dumps:
>
># dd bs=64k if=/dev/rmt/0n | ufsrestore vibf 64k -
>
>Verify volume and initialize maps
>Note: doing byte swapping
>Dump   date: Tue Jan 06 13:49:05 2004
>Dumped from: the epoch
>Level 0 dump of / (dir usr) on linuxbox:/dev/hda1
>Label: /
>Extract directories from tape
>Segmentation Fault - core dumped
>
>

So you're trying to do a Solaris ufsrestore on a Linux dump - do you
expect that to work?

Pete.

[ Post a follow-up to this message ]

Peter Bunclark wrote:
quote:

>

< lots of garbage snipped >
quote:

>
> So you're trying to do a Solaris ufsrestore on a Linux dump - do you
> expect that to work?
>
> Pete.



No, he was trying to dump from a Linux machine to a Sun tape drive and
then restore back to the Linux machine.  Nothing wrong with the
concept.  The problem is that dump for Linux does not work well.  In
Linus Torvalds' words:

"Dump was a stupid program in the first place. Leave it behind."

You can find out more about his thoughts on dump at:

http://lwn.net/2001/0503/a/lt-dump.php3

I use Gnu tar to backup machines across the network and it works fine.

Good luck,

Steve
--
 ________________________________________
_____________________
Steve Cousins                Email: cousins@umit.maine.edu
Research Associate           Phone: (207) 581-4302
Ocean Modeling Group
School of Marine Sciences    208 Libby Hall,
University of Maine          Orono ME 04469

[ Post a follow-up to this message ]

In article <3FFC4960.F89653A2@maine.edu>,
Steve Cousins  <steve.cousins@maine.edu> wrote:
quote:

> No, he was trying to dump from a Linux machine to a Sun tape drive and
> then restore back to the Linux machine.


No. he did the dump on the Linux machine to a Sun tape drive and then
tried to use ufsrestore on the Sun to read the tape:

| # dd bs=64k if=/dev/rmt/0n | ufsrestore vibf 64k -
|
| Verify volume and initialize maps
| Note: doing byte swapping
| Dump   date: Tue Jan 06 13:49:05 2004
| Dumped from: the epoch
| Level 0 dump of / (dir usr) on linuxbox:/dev/hda1
| Label: /
| Extract directories from tape
| Segmentation Fault - core dumped

He runs ufsrestore on something that has a different byte order than
the Linux machine (note the "Note: doing byte swapping" from ufsrestore)
and as restore is called restore in Linux and ufsrestore in Solaris he
certainly is not trying to do the restore on the Linux machine, most likely
on he is doing it on the Sun.
quote:

> Nothing wrong with the concept.


It will not work. The dump format is not portable between implementations.
quote:

> I use Gnu tar to backup machines across the network and it works fine.


I would never trust GNU tar to do any of my backups. It is seriously
broken and is not compatible with what the POSIX standard has to say
about tar.

--
Göran Larsson     http://www.mitt-eget.com/

[ Post a follow-up to this message ]

Goran Larsson wrote:
quote:

>
> In article <3FFC4960.F89653A2@maine.edu>,
> Steve Cousins  <steve.cousins@maine.edu> wrote:
> 
>
> No. he did the dump on the Linux machine to a Sun tape drive and then
> tried to use ufsrestore on the Sun to read the tape:


You are correct!  Sorry about that.
quote:

> | # dd bs=64k if=/dev/rmt/0n | ufsrestore vibf 64k -


As Goran says, this will not work.  ufsrestoring a linux dump is not
going to work due to different file systems as well as endian problems.
quote:

> |
> | Verify volume and initialize maps
> | Note: doing byte swapping
> | Dump   date: Tue Jan 06 13:49:05 2004
> | Dumped from: the epoch
> | Level 0 dump of / (dir usr) on linuxbox:/dev/hda1
> | Label: /
> | Extract directories from tape
> | Segmentation Fault - core dumped
>
> He runs ufsrestore on something that has a different byte order than
> the Linux machine (note the "Note: doing byte swapping" from ufsrestore)
> and as restore is called restore in Linux and ufsrestore in Solaris he
> certainly is not trying to do the restore on the Linux machine, most likel
y
> on he is doing it on the Sun.
> 
>
> It will not work. The dump format is not portable between implementations.


As I (mis)read it the concept was ok.  Of course, you can prove anything
if you start with a false premise :*)
quote:
 
>
> I would never trust GNU tar to do any of my backups. It is seriously
> broken and is not compatible with what the POSIX standard has to say
> about tar.


What do you use to backup linux machines? cpio? pax? There were a couple
of versions of Gnu tar that did have some problems but I've used Gnu tar
backups of some sort or another for many years with good results. I
primarily use it now because of the ability to do incremental backups,
which AFAIK can't be done with the non-Gnu tar.

Steve
 ________________________________________
_____________________
Steve Cousins                Email: cousins@umit.maine.edu
Research Associate           Phone: (207) 581-4302
Ocean Modeling Group
School of Marine Sciences    208 Libby Hall,
University of Maine          Orono ME 04469

[ Post a follow-up to this message ]

Steve Cousins wrote:
quote:

> No, he was trying to dump from a Linux machine to a Sun tape drive and
> then restore back to the Linux machine.  Nothing wrong with the
> concept.  The problem is that dump for Linux does not work well.  In
> Linus Torvalds' words:
>
> 	"Dump was a stupid program in the first place. Leave it behind."
>
> You can find out more about his thoughts on dump at:
>
> 	http://lwn.net/2001/0503/a/lt-dump.php3
>
> I use Gnu tar to backup machines across the network and it works fine.


There is more info about the dump 'bug' in: http://dump.sourceforge.net/isdumpd.../>
ecated.html

[ Post a follow-up to this message ]

In article <Hr5As7.JvA@approve.se>, Goran Larsson <hoh@invalid.invalid> wrot
e:
quote:
 
>
>You will find that it is likely only GNU tar that can read your
>backups. That might be ok if you know about this and treat GNU tar as
>having a proprietary format.


Beware: Even GNU tar will not read back GNU tar dumps in many cases.

In case that you need to do multi-volume backups with GNU tar, GNU tar
implements a chance from 1-5% that it will not acept a continuation
volume. Star will be able to read those multi-volume GNU tar archives but
star does not implement GNU tars pseudo incremental backup system.
The reason is that the GNU tar incremental method does not work well and sta
r
implements a better method.

--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

[ Post a follow-up to this message ]

In article <Hr5As7.JvA@approve.se>, Goran Larsson <hoh@invalid.invalid> wrote:
quote:

>In article <3FFC911D.B9C10372@maine.edu>,

quote:
 
>
>The tar implementation "star" should be able to do what you require and
>still create POSIX compliant backups.


You may already do incremental backups using star (it implements the same ba
sic
ideas as ufsdump does),  but the incremental restore is not yet ready.

In case that files have been removed or renamed, you would need this specifi
c
incremental restore feature. I expect about one man month of work until the
incremental restore is ready.

As I did rewrite about 2/3 of star during that last 6 months, I need a small
break and currently rather work on cdrtools.

--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

[ Post a follow-up to this message ]

> It will not work. The dump format is not portable between implementations.

Unless I missed something in my first post. The DUMP does work.
i.e. A sun ufsdump can "read"  linux Dump. I've done AIX dump
and if you play with the correct blocks, ufsdump can read them...

[ Post a follow-up to this message ]

On Thu, 08 Jan 2004 01:01:49 +0000, Joerg Schilling wrote:
quote:

> -	ufsdump is slow! It's antique design does not allow to have decent
> 	bufering.
>
> 	Star allows to virtually use any FIFO size. Defining e.g. 256 MB of FIFO
> 	works with star and will give you more than 30 seconds tape streaming
> 	reserve, even with modern fast tape drives.
>
> -	The ufsrestore interface ist just significantly worse and less flexible
> 	than what you may do with star when it comes to restoring only a
> 	specific choice of files.


Disclaimer:  Joerg is the author of star.

[ Post a follow-up to this message ]