> > You would need to use piping to restore the backup, though and that can
> > get tricky if your new system that you need to restore the data to isn't
> > sized the same as the old and isn't using the same version of dump.
> Woha, timeout. Are you saying 'dump' produces files in a format *not* 
> guaranteed to work with 'restore' on another system if it is not running the 
> exact same version of FreeBSD? Or having the same file system size?
> I had always assumed - given that it's a backup tool - that the format of the 
> dump was portable. 

Generally, dump files are "portable" within the same OS but different
versions.  eg a dump in FreeBSd 3.xx can be restore in FreeBSD 4.xx, etc.
But, unfortunately dump files are often not portable between OSen,
especially vendor supported proprietary versions of UNIX.  It is also
possible that it might not be portable between OS versions, but mostly
it hasn't been changing as much lately so that isn't so much a problem
as it was a few years ago.   

dump puts a "magic number" in the dump file header and restore will refuse 
to work on files that have the wrong magic number.  The magic number is
only supposed to change if a new version of dump now generates a file
that is incompatible with previous versions, but I don't know how
precise developers have been with adhering to this imperative.  
Especially between vendors, they may have changed the magic number
just because it is a different vendor and not because the file format
is any different.   But, I don't think you will find that happening
within FreeBSD. 

The issue of not being able to restore a dump if it was piped from one
system to another comes up if the two systems are different - namely
different vendors.  If you dump a FreeBSD file system and pipe it
to a SUN OS system for writing to media, for example, then a SUN OS
version of restore may well not be able to read that dump.   You 
would need to pipe it to a restore running on a FreeBSD system.   That
works OK for full restores, but can be rather nasty for restoring just
a few files or doing an interactive restore. 

But, if you pipe a dump of a FreeBSD file system to another FreeBSD
system for writing.  Then restore on that other FreeBSD system will
almost assuredly be able to read the dump.   You might want to 
experiment a little to be clear on procedures if you plan to do this.

So, all this may sound iffy, but really, if you use dump in FreeBSD
to back up a file system, (and if the media stays good, of course)
you should have no problem restoring from that dump.

And, really, for most cases of making a backup against disk failures
(and fat finger or caffeine haze failures) that would be used to 
recover files on the same system, dump is generally the best choice.
It maintains the information in a manner that can be restored to
a full working version of the filesystem with all file information
kept intact.  The other methods do not guarantee that in all cases.

dump's main weakness is that it works on a filesystem rather than 
some subset such as a few files or a specific directory tree.  

So, if you want to make a backup of just one or two directory trees 
within a filesystem, then probably tar is your best bet.   Also, if 
you want to make something that is more guaranteed to be portable 
across OS boundaries, then tar is a good choice.   Otherwise, use dump.


> -- 
> / Peter Schuller, InfiDyne Technologies HB
> PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>'
> Key retrieval: Send an E-Mail to [EMAIL PROTECTED]
> E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org
> _______________________________________________
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to