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 > > cd /MOUNTED_EMPTY_PARTITION > > 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, ////jerry > > Again, many thanks. > _______________________________________________ > email@example.com mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"