> > > 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. ////jerry > > -- > / 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 http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"