Fork: 0
tundra / baremetal
Browse code
First complete doc.
master
1 parent 58e5843 commit fa2ae2ff9f985f45241fde136c7ceb1e26eb67e5
@tundra tundra authored on 22 Aug 2014
Patch
Unified Split
Showing 1 changed file
View
181
■■■■■
 baremetal.rst
 
 
:Author: Tim Daneliuk (tundra@tundraware.com)
 
:Version: ``$Id: baremetal.rst,v 1.102 2014/08/22 23:05:22 tundra Exp $``
:Version: ``$Id: baremetal.rst,v 1.103 2014/08/22 23:38:40 tundra Exp $``
 
 
Précis
------
Backup Procedure
----------------
 
::
 
mount nas1:/shared /shared # Mount shared storage
 
 
 
Boot from the System Rescue CD
 
mount nas1:/shared /shared # Mount shared storage
 
sfdisk -d /dev/sda >/shared/ptbl # Preserve the partition table
 
dd if=/dev/sda of=/shared/MBR bs=512 count=1 # Backup the Master Boot Record
 
dd if=/dev/sda1 of=/shared/boot.dd bs=12M # Backup /boot
 
dd if=/dev/sda2 of=/shared/root.dd bs=12M # Backup rootvg LVM (rest of OS)
 
reboot machine to make it operational again
 
 
How long this takes depends on what your write speed to the shared storage is
and how big your partitions are. In this case ``sda1`` is only about 100MB
and completed rather quickly. But ``sda2`` was about 52GB and took around
25 min to complete on a slow nfs mount - about 26MB/min in this case or about
a quarter of the capacity of the 1Ge network connecting the NAS.
 
The ``bs=12`` is environment-specific and you'll have to find a setting for this
that makes best use of your network and NAS or other storage device.
 
 
Restore Procedure
-----------------
 
 
 
Now, imagine that your OS is borked or the hard disk had to be replaced and you
need to take the image from the backup above and getting running on the machine.
 
 
::
Boot from the System Rescue CD
 
mount nas1:/shared /shared # Mount shared storage
 
dd if=/dev/zero of=/dev/sda bs=512 count=10 # Nuke any old boot/partion info on the disk
 
sfdisk /dev/sda </shared/ptbl # Restore the partition table
 
dd if=/shared/MBR of=/dev/sda bs=512 count=1 # Restore the Master Boot Record
 
dd if=/shared/boot.dd of=/dev/sda1 bs=12M # Restore /boot
 
dd if=/shared/root.dd of=/dev/sda2 bs=12M # Restore rootvg LVM (rest of OS)
 
Reboot machine to make it operational again
 
On the same network described above, restoring the 52MB ``rootvg``
took about 35 mins.
 
Because this is partition based - that is, you are imaging and
restoring *partitions* not disks - you can actually restore to a
physical disk that is a different size than the one from which the
image was taken so long as there is room for all the data on the new
disk. This makes it easy to lay your operating system down on a new,
larger disk. Do an image of the old disk, restore it to the new disk,
and thenm, while still running under the ``System Rescue CD``, run
``parted`` or ``gparted`` to expand the partitions to use the
additional disk space.
 
.. warning:: **Do NOT try this with a machine that boots from SAN!!!**
SAN-booted machines put information into their
bootloaders about the boot LUN's WWID and the necessary
configuration of HBAs to see those LUNs. If you present
a bigger LUN with a different WWID, the OS bootstrap will
probably fail, even though you can properly restore the
image. There are ways around this. This document is not
the place to find these ways.
 
 
Conclusions & Limitations
-------------------------
 
- This seems to work fine in the limited configuration that was tested.
 
- The upside of this approach is that you can use standard Linux
commands to do imaged backups of your machine.
 
- There are two downsides:
 
1) You cannot do this while the machine is up and running.
 
2) Every block in the partition gets copied whether it is used or not.
- Upside:
 
1) You can use standard Linux commands to do imaged backups of
your machine.
 
2) You can use this to migrate an OS to a bigger disk.
 
- Downside:
 
1) You cannot do this while the machine is up and running so
imaging this way requires a machine outage.
 
2) Every block in the partition gets copied whether it is used or
not.
 
- In *theory* this should also work on SAN-booted machines so long as
the exact same LUN (WWID and size) is presented for the restore as
was used for the backup. However, this was not tested and theory
 
- Again, *theoretically* this should work with other operating system
partitions and data partitions. But ... not tested.
 
- This works well for Unix-style operating systems because they boot with
a full complement of drivers and discover what is on the machine
at boot time. However, Windows may have a fit if you do this,
especially if you restore to machine substantially different than
the one where the backup image was created. First of all, Windows
doesn't carry around any drivers it doesn't think it needs. Secondly,
Windows licensing logic is designed to prevent this sort of thing
as a deterrent to software piracy.
 
- This approach assumes the disk us partitioned using standard ``fdisk``
type tools. Some OSs - notably ``FreeBSD`` - have the option to use
their own disk slicing and labeling tools. This general approach will
work, but you have to tweak it to ensure you preserve those boot loaders
and custom slicing tables.
 
 
Copyright And Licensing
=======================
 
This document is Copyright (c) 2014, TundraWare Inc., Des Plaines, IL
 
 
 
 
 
 
 
60018, All Rights Reserved.
 
Permission is hereby granted for the free duplication and dissemination of
this document if the following conditions are met: