OpenBSD Journal

Upgrade Wars: Attack of the Clones

Contributed by sean on from the puffy-is-only-as-complicated-as-you-presume-it-to-be dept.

At each new release, some sysadmins seem to get a bit skittish about upgrading critical production machines. In some environments, you have to be 100% sure you won't break something or at the very least be sure to have a fall-back plan should everything go pear-shaped. While you may have a patching policy in place, upgrading the entire OS in one fell swoop can be risky business if you are not completely prepared. Too much apprehension, and you don't get to take advantage of 'the new hotness' features and possibly result in running releases with either known issues or security problems.

There is a solution however, even on a tight budget. That solution (as the title suggests) is disk cloning. If you tried this before you may be saying, "Ghost is crap: it doesn't like *BSD disks" or "must be nice to have exact duplicate disks lying around."

Those approaches are good but we can do better.

Assuming you have another disk at least as large as the current one, we can clone the currently running system using only the built in tools OpenBSD provides.

The first step depends on how paranoid you are. If you can turn off the machine, then I would suggest putting the "other drive" in the machine this way. If you cannot turn the machine off and it have a free USB port, you can use a USB to IDE/SATA adapter (slow but effective). I'm not sure if a decent USB to SCSI adapter exists, but I do know of an LVD to IDE adapter that can be chained to a USB to IDE/SATA converter. I'm not all that keen on popping drives onto an active SCSI bus but if you can find a safe way of adding another raw drive device to the machine, that's all you really need.

Make sure you've got a couple disk device nodes (ie. wd0 and wd1, or sd0 and sd1 or wd0 and sd1 etc.).

Also, in this case I'm going to clone the entire disk (label and all). You can modify this method to upgrade to larger disks (i.e. grow slices) or convert a larger sparsely used drive to a compact flash card or other medium. In order to go through all the basic steps I'll just do a straight clone.

In this case I'll say my root drive is sd0 and my destination is sd1.

Cloning a drive:

  1. We will first need save a copy of the source label. This is really easy. Just run the disklabel(8) command and store the output somewhere.
    disklabel /dev/sd0 > /tmp/label
    
  2. The next step is to initialize the second disk, we can do this by using the fdisk(8) command and tell it to re-initialize the MBR (Master Book Record). If you already have a configured partition map then feel free to move on, but we're assuming here the disc is brand new and either formatted to another system or blank from the manufacturer.
    fdisk -yi /dev/sd1
    
  3. Now that we have a copy of the source label and we've primed the destination we will need to copy that disklabel over to the new drive:
    disklabel -Rr /dev/sd1 /tmp/label
    
    NOTE: If the drives are of differing sizes you'll need to preserve the 'c' slice from the destination drive. Just copy the 'c' slice from disk label from the second drive and replace the 'c' slice in the /tmp/label and you'll be fine. This is also the point where you can change slice sizes though you'll want to use the disklabel editor if you are not comfortable editing the label manually. You can do that via disklabel -E sd1.

  4. Now we initialize the individual slices on our drive and copy the data over. You will need to create new file systems on each of the slices. I will only show how to do the first using dump(8) and restore(8), but doing the rest is just a matter of rote.
    newfs /dev/sd1a
    mount /dev/sd1a /mnt
    (dump -0f - / )|(cd /mnt/; restore -rf -)
    umount /mnt;
    
  5. Once all the slices are initialized and the data copied over, we just need to make the drive bootable, which is also deceptively easy. All we need to do is copy the bootstrap code (biosboot(8)) over to the drive and install it on to the disk using installboot(8):
    mount /dev/sd1a /mnt
    cp /usr/mdec/boot /mnt/boot
    /usr/mdec/installboot -v /mnt/boot /usr/mdec/biosboot /dev/sd1
    

That's all there is to it. You now have a clone of your disk. You can reboot it and run through the upgrade if you wish. You can even install the upgrade before rebooting by copying the release from the CD and extracting it to the new disk (you'll have to mount the slices of course).

With this method you can easily and safely upgrade your production machines to any particular release. The safety comes from being able to fall back to the previously known good drive configuration just in case something from a new release breaks your configuration and you've just got to get it working again.

Another use for this method is to do a "poor man's" RAID mirroring. You can leave the drive attached to your system and periodically, via cron(8), mirror the disk state to the other drive. Again, if you screw up or one of the drives die, you have a quick fix already raring to go. My suggestion here is to connect the drive every so often, mirror the data and when done disconnect the power and data cables (that way PSU or drive frying situation doesn't lay waste to your backup). This is a very inexpensive disaster recovery method, at least.

In case you had to do this over and over or periodically, here is a nice little script I threw together which will clone two disks (slice for slice) using everything mentioned previously.

#!/bin/sh
source=/dev/sd0
dest=/dev/sd1

# Initialize disk
disklabel $source > /tmp/label
fdisk -yi $dest
disklabel -Rr $dest /tmp/label

# Obtain slices to clone
slices=`grep ^\ /tmp/label  | cut -c 3 | grep -v c`
rm /tmp/label

# Clone each slice
for i in $slices; do
       newfs $dest$i
       mount $dest$i /mnt
       path=`df -h | grep $source$i | awk '{print $NF}'`
       (dump -0f - $path)|(cd /mnt; restore -rf -)
       umount /mnt;
done

# Install boot record.
mount ${dest}a /mnt
cp /usr/mdec/boot /mnt/boot
/usr/mdec/installboot -v /mnt/boot /usr/mdec/biosboot $dest

I hope that this article not only opened your eyes a bit as to how your system really works, even if only allowing you to hedge your bets or swoop in and save the day (like when that disk starts making a racket). Even if you don't wish to use this or prefer another method (please share), just going through this procedure once will make you more familiar with how your machine boots, is laid out and, best of all, it reduces the mysteries behind the installer (see, it is easier than you think).

(Comments are closed)


Comments
  1. By Barry (63.237.125.21) on

    Thanks much. I new this could be done, but never put all the pieces together. Will be using this for the 4.3 update.

    eSATA would be the perfect solution for the external hard drive.

    I've been trying to think of a way to have OpenBSD turn my eSATA drive on/off for that daily or weekly backup out of cron... nothing yet.

  2. By J. Raby (74.59.152.153) on

    > (dump -0f - / )|(cd /mnt/; restore -rf -)

    For bonus points, it can even be done over ssh
    (dump -0f - / )|ssh remotehost "(cd /mnt/; restore -rf -)"

    I did that a couple of time at work to backup partitions to
    a tape drive which was on a Tru64 box :
    (dump -0f - / )|ssh remotehost "(dd of=/dev/ntape/tape0_d1 bs=8192)"

    agreed, there's quite a bit of overhead because of the crypto...
    nc?

    Being able to do this sort of things is one of the reason why I love unix :)

  3. By Lennie (82.75.29.106) on

    I'm originally from the Linux-camp, dump/restore isn't really supported (Linus himself doesn't think to highly of it). And that's why I've grown accustomed to using rsync (over the network, a lot of the time with ssh in between).

    It's just what I use, sysadminjobs are like perl, there is more then one way to do it. :-)

    Comments
    1. By Anonymous Coward (194.245.32.131) on

      > I'm originally from the Linux-camp, dump/restore isn't really supported (Linus himself doesn't think to highly of it). And that's why I've grown accustomed to using rsync (over the network, a lot of the time with ssh in between).
      >
      > It's just what I use, sysadminjobs are like perl, there is more then one way to do it. :-)

      you could use xfs filesystems; their supporting their xfsdump and xfsrestore and it does a great job

  4. By David (76.24.31.220) david@datashadow.net on http://www.datashadow.net

    You can also use rsync to keep your cloned copy up-to-date on an on-going basis...

    One drawback to the the above methods is that they try to capture the state of the system while it is running. This can cause problems with open files (especially bad for databases). It's best to clone the system while it's "cold", such as booted from a CD or an alternate HD.

    Here is one method for cloning a system that minimizes the time that it is off-line:

    1. Start by cloning the system while it's "hot" (still up, running, and on-line). This does the bulk of the work, and safely gets all of the "static" data, while you're still on-line.

    2. Pick a time when being off-line is acceptable. Shutdown, and reboot from CD (or an alternate HD, if you're so blessed)

    3. Use rsync to copy the files that were "open", and or changed between the "live" cloning and the pre-rsync shutdown.

    4. Power back up with either the the original drive, or the clone. Beware of changed mount points in /etc/fstab if you do boot off the clone (without physically swapping it for the original drive).

    The rsync copy will go much faster than the cloning, since rsync will copy only the files that have changed. Rsync has much less work to do than the cloning copy which has to copy *ALL* of the data.

    If there is a long time between steps 1 and 2 you can use a step 1.5 to do a "hot" rsync just before shutdown and the "cold" rsync. The definition of "a long time" is up to you, and how fast your data changes. Running step 1.5 can also give you a better idea of just how long your down-time will be

    I've come up with a couple of scripts (BSD & Solaris) for both cloning drives and keeping the clones up to date with rsync. I'll polish them up and make them available if anyone's interested.

    David

  5. By Anonymous Coward (216.68.198.1) on

    Usefull article, very important matter, thank you and comments help. Why not OpenBSD FAQ 4.13, use siteXX.tgz method. Haven't used it yet. Gzip, grr, sometimes compression programs have security issues, even file program in OpenBSD 4.1, had issues.
    Dump/restore, grr, even different versions of the filesystem, from 3.9 to 4.2, things get a bit fscked and versions have subtle differences.
    Upgrades really are just +.1 version! But sometimes having older systems is REAL WORLD and no upgrade, thus a verified method is needed. I reinstall, move lots, disk to disk/s. GRR. This is JUST for content that doesn't deal with symbolic links issues. GRR.
    Sysadmin requires some sanity and ease of use and lack of PAIN. As is obvious, I need to work on this subject more. Lots of different ways.

    I have been thinking about a custom mtree method to verify files and the new OS with necessary changes, GRR, haven't done yet, wonder if any have gone down this path? Sure would be nice if mtree had a few little additions for this use, like translation lists, and compliance to custom lists, if deemed appropriate, although why reinvent the wheel of siteXX.tgz, and install script? Perhaps mtree might have more checking, although YMMV. Aide program as well, might be an option, but it is complex and had some security issues in past as well. GRR, sure takes a long time to get some SOLID procedures down SQUARE that last from release to release for YEARS!

    Perhaps a good FAQ/FGA for this could help for environments where versions are different, and perhaps across BSD systems. Yeah, I like to be spoiled.

    Comments
    1. By Marc Espie (213.41.185.88) espie@openbsd.org on

      > Upgrades really are just +.1 version! But sometimes having older systems is REAL WORLD and no upgrade, thus a verified method is needed. I reinstall, move lots, disk to disk/s. GRR. This is JUST for content that doesn't deal with symbolic links issues. GRR.

      Actually, updating the system over several releases doesn't work that bad.
      I updated a system from 3.6 to 4.3 for tests, and I was very pleased with how little breakage I got.

      Make no mistakes, things are steadily improving, and this is not a trend I see going backwards.

  6. By Anonymous Coward (208.77.91.37) on

    While cloning disks is good I've always felt that upgrade path for OpenBSD is a little rough.

    Some other unix-like operating systems have come up with tools that perform the all necessary operations (apt, yum). Yes, I know BSD is not the same but that does not mean it can't become easier.

    The same applies also to patch branch. I think it would be very nice to be able to have a binary upgrade option available to follow the stable.

    Comments
    1. By kiriakos mountakis (62.103.255.186) on

      > While cloning disks is good I've always felt that upgrade path for OpenBSD is a little rough.
      >
      > Some other unix-like operating systems have come up with tools that perform the all necessary operations (apt, yum). Yes, I know BSD is not the same but that does not mean it can't become easier.
      >
      How can you favour "run apt-get dist-upgrade and no matter what site configuration, no matter what version you're upgrading to, everything will will work fine." over OpenBSD's upgrade support (detailed description of possible problems you would encounter for each specific release, in the upgrade-guide, for both base system and ports??!)
      I mean, that's a feature unique to OpenBSD, wich AMONGS OTHERS, proves it's quality.I personally tried to find this kind of upgrade support and i was totally dissapointed by all other BSD flavours too.
      Really weird stuff..maybe you're just running a desktop system, so that when the weather report desktop applet malfunctions after an upgrade, its OK.
      PS: I've been a debian/ubuntu administrator for years.So many multiple frustrations from upgrades..
      > The same applies also to patch branch. I think it would be very nice to be able to have a binary upgrade option available to follow the stable.
      It never took me more than 15minutes to update a subportion of the base system (when i really should).Just because the update procedure is so simple and only updates necesseray portions of the system, it's the first time in my life when i even read the patches and actually know what has to be patched and why.
      I mean..in my point of view..just don't fsck with OpenBSD in those sections you mentioned..

      Comments
      1. By Anonymous Coward (208.77.91.37) on

        > > Some other unix-like operating systems have come up with tools that perform the all necessary operations (apt, yum). Yes, I know BSD is not the same but that does not mean it can't become easier.
        > >
        > How can you favour "run apt-get dist-upgrade and no matter what site configuration, no matter what version you're upgrading to, everything will will work fine." over OpenBSD's upgrade support (detailed description of possible problems you would encounter for each specific release, in the upgrade-guide, for both base system and ports??!)
        > I mean, that's a feature unique to OpenBSD, wich AMONGS OTHERS, proves it's quality.I personally tried to find this kind of upgrade support and i was totally dissapointed by all other BSD flavours too.

        I am absolutely not against OpenBSD's detailed descriptions, they are valuable. However, I think there needs to be tools in base for automation of it.

        > PS: I've been a debian/ubuntu administrator for years.So many multiple frustrations from upgrades..

        Interestingly our experience differ in that matter. I too have been debian admin for years and so far, all upgrades I have done have worked without problems. May be I've been lucky, but that's what I've seen.

        > > The same applies also to patch branch. I think it would be very nice to be able to have a binary upgrade option available to follow the stable.
        > It never took me more than 15minutes to update a subportion of the base system (when i really should).Just because the update procedure is so simple and only updates necesseray portions of the system, it's the first time in my life when i even read the patches and actually know what has to be patched and why.

        That's great, but imho updates like that should be available in binary format too. If one can binary upgrade between releases, one should be able to binary upgrade within the release. And even tho I could make my own sets and automate things, I shouldn't need to reinvent that wheel or resort to third party tools. It's just busy work I think can be cut down.

        > I mean..in my point of view..just don't fsck with OpenBSD in those sections you mentioned..

        You sound protective. But I don't fsck anything, I want OpenBSD to become better. OpenBSD has grown when it has offered something better than before (OpenSSH, Open_so_many_other_projects, pf, CARP, etc). I just happen to think by offering improved upgrade path OpenBSD can grow more.

        Comments
        1. By Anonymous Coward (62.103.255.140) on

          > > > Some other unix-like operating systems have come up with tools that perform the all necessary operations (apt, yum). Yes, I know BSD is not the same but that does not mean it can't become easier.
          > > >
          > > How can you favour "run apt-get dist-upgrade and no matter what site configuration, no matter what version you're upgrading to, everything will will work fine." over OpenBSD's upgrade support (detailed description of possible problems you would encounter for each specific release, in the upgrade-guide, for both base system and ports??!)
          > > I mean, that's a feature unique to OpenBSD, wich AMONGS OTHERS, proves it's quality.I personally tried to find this kind of upgrade support and i was totally dissapointed by all other BSD flavours too.
          >
          > I am absolutely not against OpenBSD's detailed descriptions, they are valuable. However, I think there needs to be tools in base for automation of it.
          >
          > > PS: I've been a debian/ubuntu administrator for years.So many multiple frustrations from upgrades..
          >
          > Interestingly our experience differ in that matter. I too have been debian admin for years and so far, all upgrades I have done have worked without problems. May be I've been lucky, but that's what I've seen.
          >
          > > > The same applies also to patch branch. I think it would be very nice to be able to have a binary upgrade option available to follow the stable.
          > > It never took me more than 15minutes to update a subportion of the base system (when i really should).Just because the update procedure is so simple and only updates necesseray portions of the system, it's the first time in my life when i even read the patches and actually know what has to be patched and why.
          >
          > That's great, but imho updates like that should be available in binary format too. If one can binary upgrade between releases, one should be able to binary upgrade within the release. And even tho I could make my own sets and automate things, I shouldn't need to reinvent that wheel or resort to third party tools. It's just busy work I think can be cut down.
          >
          > > I mean..in my point of view..just don't fsck with OpenBSD in those sections you mentioned..
          >
          > You sound protective. But I don't fsck anything, I want OpenBSD to become better. OpenBSD has grown when it has offered something better than before (OpenSSH, Open_so_many_other_projects, pf, CARP, etc). I just happen to think by offering improved upgrade path OpenBSD can grow more.

          It may sound strange, but if i see openbsd offering automated upgrade/update procedures, i would get very displeased.The reason is i wouldn't like any extra complexity overhead since i can do my job right now with such confidence you see..

    2. By Noryungi (noryungi) on

      While cloning disks is good I've always felt that upgrade path for OpenBSD is a little rough.

      Uh?

      Some other unix-like operating systems have come up with tools that perform the all necessary operations (apt, yum). Yes, I know BSD is not the same but that does not mean it can't become easier.

      Here is how to do it the easy way:

      - Boot on the CD-ROM

      - Select 'U' for Upgrade

      - Once the upgrade has been performed, reboot your computer

      - Make sure your root .profile is configured correctly, with a valid PKG_PATH

      - As root, enter:
      pkg_info | awk '{print $1}' | xargs pkg_add -u -vv -i

      That's it, your system is now up-to-date to the latest version (system+packages). Your configuration is intact, your personal directories are there and the machine should be up and running.

      Is that so complicated?

      Please note that the only exception to the above is if you have a wifi adapter on your machine (like I do) in which case you may need to download an upgraded firmware.

      I have done this on 3+ personal machines for at least 3 or 4 past versions of OpenBSD and I have never had any problem. These are not production machines, but OpenBSD has never let me down in that respect.

      The same applies also to patch branch. I think it would be very nice to be able to have a binary upgrade option available to follow the stable.

      Agreed. That's about the only thing I would say is missing from OpenBSD. There were some sites that offered binary upgrades though.

      Comments
      1. By sthen (2a01:348:108:155:20a:e4ff:fe2d:99ee) on

        > Here is how to do it the easy way:
        > - Boot on the CD-ROM
        > - Select 'U' for Upgrade
        > - Once the upgrade has been performed, reboot your computer

        Please don't forget /etc and friends (mergemaster, in packages, is the easy way). Sometimes bugs are fixed, e.g. in /etc/rc or /etc/netstart (as happened between 4.2 and 4.3). Occasionally there are other steps too: -current users should see http://www.openbsd.org/faq/current.html - when upgrading between versions there's a guide produced for each version e.g. http://www.openbsd.org/faq/upgrade42.html.

        Even if you make a clean installation rather than upgrading, it's a good idea to read these guides - they will highlight some important changes (e.g. the recent flag day for carp(4) with IP or ARP balancing).

        > - Make sure your root .profile is configured correctly, with a valid PKG_PATH
        > - As root, enter:
        > pkg_info | awk '{print $1}' | xargs pkg_add -u -vv -i

        "pkg_add -ui" defaults to updating everything you have installed - no need for the pkg_info part.

      2. By Anonymous Coward (208.77.91.37) on

        > Here is how to do it the easy way:
        > - Boot on the CD-ROM
        > - Select 'U' for Upgrade
        > - Once the upgrade has been performed, reboot your computer
        > - Make sure your root .profile is configured correctly, with a valid PKG_PATH
        > - As root, enter:
        > pkg_info | awk '{print $1}' | xargs pkg_add -u -vv -i
        >
        >
        > That's it, your system is now up-to-date to the latest version (system+packages). Your configuration is intact, your personal directories are there and the machine should be up and running.
        >
        > Is that so complicated?

        No, that is not, but it is when boxes are in remote location(s). I think upgrading should as simple for remote boxes as it is for local ones. But right now there is a lot more busy work for the latter option. It is possible to automate it, but I think this needs to be in the base tested and true rather than most people needing to reinvent the same wheel.

        > The same applies also to patch branch. I think it would be very nice to be able to have a binary upgrade option available to follow the stable.
        >
        > Agreed. That's about the only thing I would say is missing from OpenBSD. There were some sites that offered binary upgrades though.

        Yes, but I wish it would be in the base.

        Comments
        1. By oga (87.194.220.76) oga@openbsd.org on

          > > Here is how to do it the easy way:
          > > - Boot on the CD-ROM
          > > - Select 'U' for Upgrade
          > > - Once the upgrade has been performed, reboot your computer
          > > - Make sure your root .profile is configured correctly, with a valid PKG_PATH
          > > - As root, enter:
          > > pkg_info | awk '{print $1}' | xargs pkg_add -u -vv -i
          > >
          > >
          > > That's it, your system is now up-to-date to the latest version (system+packages). Your configuration is intact, your personal directories are there and the machine should be up and running.
          > >
          > > Is that so complicated?
          >
          > No, that is not, but it is when boxes are in remote location(s). I think upgrading should as simple for remote boxes as it is for local ones. But right now there is a lot more busy work for the latter option. It is possible to automate it, but I think this needs to be in the base tested and true rather than most people needing to reinvent the same wheel.


          what's so hard about:
          cd /
          cp sets/bsd /bsd
          for i in sets/*.tgz; do
          tar xzpvf sets/$i.tgz;
          done
          reboot

          Comments
          1. By Anonymous Coward (87.178.157.140) on

            > > > Here is how to do it the easy way:
            > > > - Boot on the CD-ROM
            > > > - Select 'U' for Upgrade
            > > > - Once the upgrade has been performed, reboot your computer
            > > > - Make sure your root .profile is configured correctly, with a valid PKG_PATH
            > > > - As root, enter:
            > > > pkg_info | awk '{print $1}' | xargs pkg_add -u -vv -i
            > > >
            > > >
            > > > That's it, your system is now up-to-date to the latest version (system+packages). Your configuration is intact, your personal directories are there and the machine should be up and running.
            > > >
            > > > Is that so complicated?
            > >
            > > No, that is not, but it is when boxes are in remote location(s). I think upgrading should as simple for remote boxes as it is for local ones. But right now there is a lot more busy work for the latter option. It is possible to automate it, but I think this needs to be in the base tested and true rather than most people needing to reinvent the same wheel.
            >
            >
            > what's so hard about:
            > cd /
            > cp sets/bsd /bsd
            > for i in sets/*.tgz; do
            > tar xzpvf sets/$i.tgz;
            > done
            > reboot

            Well, I once did such a thing but it fscked up my box. It was a soekris with not enough free cf-disk memory and the unpacking was incomplete. The box was unusable. Of course there was no warning or anything.

            Since I am not a very experienced user of OpenBSD yet, it took out the system for some time (which is an understatement).

            Had such a thing happened to a remote system ... ugly.

  7. By andy (81.247.26.55) on

    don't forget dd (or its cousins) (if you can get off-line).
    as with dump, you can do it over ssh as well, and pipe thru gzip or tar to compress.
    It doesn't care about the underlying filesystem, so you can copy that weird ntfs partition :-)
    contra ? yes its copies everything, even the unused space on the drive/partition.

  8. By Anonymous Coward (195.29.148.251) on

    I use combination of CARP and binpatch for all production machines. Of course it requires redundant machines but hey, we're talking production here.

    Comments
    1. By Anonymous Coward (24.37.242.64) on

      > I use combination of CARP and binpatch for all production machines. Of course it requires redundant machines but hey, we're talking production here.
      >

      Write an article on what you do and how.

      Comments
      1. By Anonymous Coward (87.144.95.5) on

        > Write an article on what you do and how.

        Please? ;)

  9. By Anonymous Coward (84.196.222.35) on

    > Make sure you've got a couple disk device nodes (ie. wd0 and wd1, or sd0 and sd1 or wd0 and sd1 etc.).

    running on 4.x doesn't provide e.g. /dev/wd0 anymore

    # cd /dev; sh MAKEDEV wd0

    also doesn't create the needed /dev/wd0 device node

    disklabel happyly takes wd0 as an argument, so with minor changs to your script it can be made to work.


    Comments
    1. By Anonymous Coward (84.196.222.35) on

      I made a few changes to the script to get it to work:

      #!/bin/sh
      sourcedisk=wd0
      targetdisk=wd1
      source=/dev/$sourcedisk
      dest=/dev/$targetdisk
      
      # Initialize disk
      disklabel $sourcedisk > /tmp/label
      fdisk -yi $targetdisk
      disklabel -Rr $targetdisk /tmp/label
      
      # Obtain slices to clone
      slices=`grep "^ " /tmp/label  | cut -c 3 | grep -v c`
      rm /tmp/label
      
      # Clone each slice
      for i in $slices; do
             newfs $dest$i
             mount $dest$i /mnt
             path=`df -h | grep $source$i | awk '{print $NF}'`
             (dump -0f - $path)|(cd /mnt; restore -rf -)
             umount /mnt;
      done
      
      # Install boot record.
      mount ${dest}a /mnt
      cp /usr/mdec/boot /mnt/boot
      /usr/mdec/installboot -v /mnt/boot /usr/mdec/biosboot $targetdisk
      

      I added two variables to hold just the disknames and used those for the commands that also take this abbreviated form (disklabel, installboot, fdisk)

      I also changes ^\ to "^ " which is more readable and better shows that there should be two spaces behinde the backslash, now there is only one, which simply hangs the grep command waiting for input

      Hoping this helps others trying to get this script to work

      And last but not least, THANKS A LOT for this post/script. I literally had a post-it on my desk today telling me to "FINALLY FIX THAT BACKUP TO SECOND DISK" ;-)

      Comments
      1. By Anonymous Coward (89.191.97.92) on

        > I made a few changes to the script to get it to work:

        #!/bin/sh
        dd if=/dev/wd0c of=/dev/wd1c

        Comments
        1. By Anonymous Coward (24.37.242.64) on

          > > I made a few changes to the script to get it to work:
          >
          > #!/bin/sh
          > dd if=/dev/wd0c of=/dev/wd1c
          >

          Never tried that, does it fully work and make it bootable too?

          Also, there's Ghost 4 Unix (G4U):
          http://www.feyrer.de/g4u/

          Comments
          1. By funky (84.126.117.244) on

            > > > I made a few changes to the script to get it to work:
            > >
            > > #!/bin/sh
            > > dd if=/dev/wd0c of=/dev/wd1c
            > >
            >
            > Never tried that, does it fully work and make it bootable too?

            It does, at least with linux, I'm quite sure it would do for BSD too.
            I've used dd for many many times to clone disks, the only problem is the partition table when you use different size disks.

    2. By Anonymous Coward (91.50.238.123) on

      These kids today ... dump-restore was common practice and knowledge since at least the late nineties. Used that for cloning Sun disks. Hardly "news that matters".

      Oops, my bad. This is Undeadly, not Slashdot. Well, ok, never mind :)

  10. By Anonymous Coward (129.27.142.194) on

    Isn't this entire procedure how you would restore a backup of the entire system onto a fresh disk?

  11. By Bayu Krisnawan (krisna) krisna@infobsd.org on http://www.infobsd.org

    Hmm nice.. But,
    How about upgrading without making our system down? Is that possible?

    Comments
    1. By Anonymous Coward (62.167.101.242) on

      > Hmm nice.. But,
      > How about upgrading without making our system down? Is that possible?

      http://openbsd.org/faq/upgrade42.html#upgrade
      See "Upgrading without install kernel"
      You still have to reboot once though.

  12. By Ted Walther (24.84.160.227) on http://reactor-core.org/

    A number of years ago I had the same problem. At the time, I needed to clone FreeBSD, NetBSD, OpenBSD and Linux hard drives. And I didn't have a floppy drive or cdrom to use as a "staging area" to hold the boot sectors. Back then bootloaders weren't nearly as nice and advanced as they are now. Accomplishing this task was a pain in the butt.

    So I wrote it up into a little HOWTO. You can still view it here Migrating Your System to Another Hard Drive. The procedure still works, although the document shows its age. It just uses tar, mkdir, and fdisk.

  13. By Robert D. Skeels (rdsathene) rdsathene@sbcglobal.net on http://rdsathene.blogspot.com/

    This technique literally saved our bacon at my day job. We have some older DNS servers which are also running ht://Dig for our entire company. The hard drive in the primary DNS was beginning to fail, and was at the stage that it was becoming more corrupted by the day. At first we were going to set up a new server, but soon found ht://Dig doesn't run on newer versions of OpenBSD. Not to mention we were uneasy at having to recreate all new DNS conf files from scratch. We needed to preserve the existing setup or have a lot of work ahead of us.

    We tried many other methods including dd through ssh to a drive installed on another host, but nothing worked. We found this, and tried it (with modifications for IDE style disks) as a last resort. The technique worked flawlessly and the server is now running without a hitch on the replacement hard drive.

    We installed secondary drives in all those servers and now use this, as you say, a poor man's raid. We're so grateful for this.

  14. By bendi (2.12.157.247) on

    You should also adapt fstab with the destination duid to get the clone fully working.
    My script working on OpenBSD 5.4:
    #!/bin/sh
    source=wd0
    dest=sd0
    
    sourceduid=`disklabel $source | grep duid |  awk '{print $NF}'`
    destduid=`disklabel $dest | grep duid |  awk '{print $NF}'`
    
    # Initialize disk
    disklabel $source > /tmp/label
    fdisk -yi $dest
    disklabel -R $dest /tmp/label
    
    # Obtain slices to clone
    slices=`grep ^\  /tmp/label  | grep -v swap | cut -c 3 | grep -v c`
    rm /tmp/label
    
    # Clone each slice
    for i in $slices; do
           newfs $dest$i
           mount /dev/$dest$i /mnt
           path=`df -h | grep $source$i | awk '{print $NF}'`
           (dump -0f - $path)|(cd /mnt; restore -rf -)
           umount /mnt;
    done
    
    # Install boot record.
    mount /dev/${dest}a /mnt
    unalias cp
    cp /usr/mdec/boot /mnt/boot
    /usr/mdec/installboot -v /mnt/boot /usr/mdec/biosboot $dest
    
    # Adapt fstab with correct duid
    sed "s/$sourceduid/$destduid/g" /etc/fstab > /mnt/etc/fstab
    umount /mnt
    

    Comments
    1. By kevin (50.143.153.66) kevingnet@gmail.com on guerra

      Horrible waste of time. Wasted about 3 hours, then finally got it to work, except that it didn't like the user's database. Retarded in single user mode and tried to recreate the users, including root, no dice!

      Then, I thought, hey, why not just reinstall and then copy the files, that only took a few minutes and I was back in business and happy again.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]