Producing Bad Dumps

Jerry McAllister jerrymc at
Fri May 29 17:58:08 UTC 2009

On Fri, May 29, 2009 at 12:17:33PM -0500, Martin McCormick wrote:

> Jerry McAllister writes:
> > Probably you did not want the -x or -u, but instead wanted to do
> >   restore -rf DUMPFILENAME
> 	That would be the ideal command. Per haps there is a
> better approach so I am all ears as the saying goes.
> 	I am trying to set up a procedure so that we can take
> another server, if necessary, format the drive with FreeBSD and
> then restore the contents of a dead server to this drive and
> have it ready to run.

Yes, you would want to use restore -r for that.

> 	Of course, dd is great if both drives are the same size
> but usually, the only thing both servers have in common is they
> are both i86 systems and the goal is to try to get a platform
> with a melted hard drive or mother board back on line. The holy
> grail is a clone operation that can be documented so that a
> worker of reasonable knowledge can do it successfully.

You don't really want to use dd for that, partly for the reason
that you give and partly because it doesn't allow the [new] system
to do things such as assign inodes and space efficiently.

> 	So, you need all the files, but they probably will not
> occupy a disk that looks like the original one. In that respect,
> tar does well but trashes special files like /dev
> > But, I am not sure because it is hard to understand why you chose -xu.
> 	The thought was that -u unlinks existing files so one
> could write the restore right over the minimal system that was
> there. -x was to extract / in order to get the entire root file
> system.

Well, you don't really want to create a minimal system on the device
if you don't have to.
You just want to slice (fdisk), partition(bsdlabel) and newfs it (using
either sysinstall or manually fdisk, bsdlabel and newfs from a fixit) and 
then use a fixit CD to write the dump to the device with restore -r.  That 
might be a problem if you are trying to read the dump from a remote storage.
I don't know if the fixit has enough stuff to do that - it might.

In that case, you might be better off having a spare drive you can
plug in and build that minimal system on and then use it to build 
the full system and repopulate it from the remote dump file with
 restore -r.

Actually, I think if you use restore -r it will behave OK writing over
existing files.   All the warning about it needing to be a clean file
system is mostly so you won't overwrite something you do not want to.

But, it leaves the possible problem that some vestigial stuff will be
left around from the minimal install you overwrite with files you 
really don't want to be left around - eg files it has that are not
duplicated in the dump so it ignores them and leaves them there.

Try it out that way.   Just use  restore -rf and see how it handles it.

> 	Again, the idea is to recover a FreeBSD system as
> quickly as possible and get it back to the patch level and
> general operating conditions it was originally in before the
> hardware that supported it died.

If you made your own 'spare' disk that could be plugged in, you could
script rebuilding the new disk and restoring the dump.  You might have
to tinker a bit.    We used to have a complete setup that built the
disk and then restored from a backup that we distributed.   It did
the disk slicing, then asked if it was a new install or if a restore
from backup was desired and did it.   That took a lot of writing in C
and it needs to be rewritten since FreeBSD 4.   But, it is readily doable.

Have fun,


> Again, many thanks.
> _______________________________________________
> freebsd-questions at mailing list
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at"

More information about the freebsd-questions mailing list