backups & cloning

Wed Sep 30 15:22:18 UTC 2009

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     

> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"