On Tue, Sep 29, 2009 at 07:44:38PM -0400, PJ wrote: > I am getting more and more confused with all the info regarding backing > up and cloning or moving systems from disk to disk or computer to computer. > I would like to do 2 things: > 1. clone several instances of 7.2 from and existing installation > 2. set up a backup script to back up changes either every night or once > a week > > There are numerous solutions out there; but they are mostly confusing, > erroneous or non functional. > To start, could someone please explail to the the following, which I > found here:http://forums.freebsd.org/showthread.php?t=185
This page is essentially correct. But, it covers several situations. You need to decide which situation you are working on. Are you trying to make a backup of your system in case something fails or are you trying to make a clone to boot in another system? As for the restore, are you trying to use it to create a disk to move to another machine to boot with or to recover a failed disk on the same machine or just have a bootable disk handy if your current one fails? Each is different. If you are just making a dump in case of a disk failure, then just dump to a file on some removable media (USB drive, Tape, across the net, etc) and forget about doing the restore for now. You do that if the disk fails and you have acquired a new disk and prepared it for service including slicing and partitioning and putting an MBR on it and a boot sector. Then you use the fixit boot to restore those backups. If you are making a clone drive to move to another system then you have to slice and partition the new drive and then do the piped dump-restores you indicate below. If you are making a disk to switch to in case of a failure, you start by making a slice and partitioned drive and do the dump-restores. But, then you keep it current using rsync. Note that in this case, you only do the dump-restore once. The rsync does all the updating. Alternatively you might use some of the mirroring software to make a mirror drive that is [almost] always an exact copy. That is a completely different process. If you are making a disk to move to another machine then you probably do not want the -u switch on the dump command. That is meant for making a series of full and change dumps as backups. > > You can move system from disk to disk on fly with > Code: > > $ newfs -U /dev/ad2s1a > $ mount /dev/ad2s1a.... /target > $ cd /target > $ dump -0Lauf - /dev/ad1s1a | restore -rf - > > you can do the same using sudo > Code: > > $ sudo echo > $ sudo dump -0Lauf - /dev/ad1s1a | sudo restore -rf - > > This may be clear to someone; it certainly is not to me. > As I understand it, newfs will (re)format the slice. > Ok, But what is standard out in the above example. The dump is from > where to where? > Could someone clarify all this for me? The only thing the sudo does is make you root. If you are already root, you don't need it - as in the first example you give. In this particular case, it is probably better to just be root and run this as root. That wouldn't always be the case in every sudo situation. The dump command as you give it reads the /dev/ad1s1a file system and sends it to standard out. That is what the '-f -' part of the command tells it. The restore command reads from standard in and restores the data sent to it from the dump via the pipe which is the '|'. The pipe takes whatever is in the standard out from where it is coming and puts it in the standard in where it is going. > So far, I have been unable to dump the / slice, not even with the -L > option. I am trying to dump the whole system (all the slices)except swap > to a usb (sata2 500gb disk) and then restore to another computer with > 7.2 minimal installation. > Slices ad2s1d,e,f and g dump ok to usb. a does not - errors ("should use > -L when dumping live filesystems) So, what are the errors. > Do you have to newfs each slice before restoring? But if you are > restoring on a running 7.2 system, don't you have to restore to another > disk than the one the system is on? You have asked two unrelated questions. First: No, but it is a convenient way to make sure there is a clean receiving place. Actually, I don't bother doing the restore. I just write a dump file and leave it there in case I need to restore from it later. So my dump command would look something like: dump -0Laf /target/ad1s1adump /dev/ad1s1a So the file ad1s1adump would contain the dump. You might add in some characters that identify the date of the dump in the name of the file. Also, you can mount the source filesystem and dump using the mount name. So, if /dev/ad1s1a is normally mounted as /work, then it would work - and be mnemonic to do: dump -0Laf /target/workdump.20090930 /work Second: You cannot unmount a filesystem that is in use. But if you have permissions you can write to it. But, if you try to restore to the root filesystem of a running system, you can potentially really trash things. So, if you want to build a disk with dump-restores you want it to be on another disk. If you want, you could dump a filesystem and write the dump to a file on any filesystem that has room for it. After all, it is just a file. Or you could create a new directory where there is lots of room and do the dump piped to restore in to that new directory. But, there is not much reason to do that unless you are just practicing with dump and restore. Doing that you haven't really created anything except a copy of stuff in a place where it would also be lost if the disk failed. So, it only makes sense to write a dump to some media other than where you are reading it from - another disk, tape, wherever. > I am beginning to think that you have to have a system running and dumpt > to another disk on that system and then remove that disk and install in > another box and boot from that? > Am I getting close? > I know it's a lot to ask, but then, I know you guys are capable... :-) You are making it much more complicated than necessary. It is true that the most complete and pristine set of dumps can only be made from a system that is down in single user mode or even more so, from a separate boot from a fixit CD or other boot device. But in reality, that is rarely done. Systems cannot be taken down and left down for great lengths of time like that. So, dumps are normally made on and from running systems. Where you write the dump to and in what form is determined by what use you want to make of the dump as I mentioned above. Really, just pick your media. The dump system still assumes it is tape so if you don't use any -f then it will try to write to a tape drive. But, -f somefile or -f somedevice is now the norm. ( a pipe '|' is common if it goes directly to a restore or goes over the net to another host) Then write the dump to it and you have a backup. I do not know why your root dump is not working. You said there are errors, but I am not used to using my telepathic powers so I am having trouble seeing what those errors are. It might clear up a little if you reported them in your post, though I can't be sure of that. ////jerry > _______________________________________________ > 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"