This guide will help you to move a ClearOS system in case of failure of your hardware. This assumes that your ClearOS server as written to the hard drive is in tack but your hardware has changed. You can move the hard drive or you can move all the data.
ClearOS is very good at reallocating resources and dynamically assigning new drivers to all of the hardware but that doesn't necessarily mean that placing your ClearOS hardware in a new device will make it work without intervention. For the most part, everything should work except for the following:
Your hard drives should know about themselves for the simple fact that they reference themselves by the names on their partitions rather than by some sort of order that may get messed. The exclusion to this is RAID. You may need to properly allocate devices for them to work well, if you are running into issues related to this, a ClearOS CD with the rescue mode or running Rescue mode from the ClearBOX menu at boot can help you get past this issue, but you may need professional services support through ClearCARE.
Failure to use the network cards after a hardware swap is the most common issue related to this task. This is because the drivers to the network cards are only part of the issue. Configuration is the other and ClearOS keeps the MAC addresses of the network cards on file. So chances are, you are reading this because your network card configuration stored on the hard drive does not match the real and current MAC addresses.
This is easy to fix.
First, we need to find out what the MAC addresses are as ClearOS now sees them. From the console, drop to a command prompt and log in as root by typing Ctrl+Alt+F2. Then we will use 'dmesg' which is a command that shows you a log of messages from the kernel. This includes messages from the kernel when it booted and saw your network card. This log can be lengthy so we will pipe the output to 'less' so that we can browse it.
dmesg | less
You can scroll through every thing but less allows us to jump right to the lines we need. In particular, we are looking for 'eth' devices like 'eth0', 'eth1' and others. To search the 'less' output type a forward slash and the search term. For example:
If the first result doesn't find the line you want, press 'n' for next.
Here is an example of what might come up:
tg3 0000:04:00.0: eth0: Tigon3 [partno(BCM95721) rev 4101] (PCI Express) MAC address 00:18:8b:11:22:33 tg3 0000:04:00.0: eth0: attached PHY is 5750 (10/100/1000Base-T Ethernet) (WireSpeed, EEE) tg3 0000:04:00.0: eth0: RXcsums LinkChgREG MIirq ASF TSOcap tg3 0000:04:00.0: eth0: dma_rwctrl dma_mask[64-bit] e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI e100: Copyright(c) 1999-2006 Intel Corporation alloc irq_desc for 32 on node -1 alloc kstat_irqs on node -1 e100 0000:03:01.0: PCI INT A -> GSI 32 (level, low) -> IRQ 32 e100 0000:03:01.0: PME# disabled e100 0000:03:01.0: eth1: addr 0xfe9ff000, irq 32, MAC addr 00:03:47:aa:bb:cc alloc irq_desc for 18 on node -1 alloc kstat_irqs on node -1
From my output I can see that I have 2 network cards, tg3 and e100 which my ClearOS automatically assumes is eth0 and eth1 respectively. The most important bit here is the 'eth' designation and the MAC addresses. You'll want to write this part down as it is output from your command. For mine, I would write:
eth0 - 00:18:8b:11:22:33 eth1 - 00:03:47:aa:bb:cc
To quit 'less', type 'q'.
Now that we have the eth designations and the MAC addresses, we need to edit the files that configure the MAC addresses. Navigate to the directory that contains these files by typing:
Type the following to find out how many network cards your system used to have:
ls -la ifcfg-eth*
Your output may look like this:
-rw-------. 1 root root 144 Mar 5 19:03 ifcfg-eth0 -rw-------. 1 root root 141 Jun 10 13:19 ifcfg-eth1 -rw-------. 1 root root 137 Jun 10 13:21 ifcfg-eth1:0
We can ignore any 'virtual' devices, which are the ones that have a colon after them. Let us start with 'ifcfg-eth0'. We will use either 'nano' or 'vi' to edit the file and fix the MAC address. If you aren't familiar with 'nano' or 'vi' use 'nano' to edit the file:
The part of the file that needs changing is ONLY the line which states 'HWADDR'. Edit the MAC address and replace it with the values you derived from the 'dmesg'.
DEVICE=eth0 TYPE="Ethernet" ONBOOT="yes" USERCTL="no" HWADDR="00:18:8b:ab:cd:ef" BOOTPROTO="static" IPADDR="10.10.10.1" NETMASK="255.255.255.0"
You can see that the address is wrong here, so change it to what it should be. Once you have written the file, go onto the other network cards and fix their addresses as well. Once you are all done, reboot and see if everything works.
For a data move from one complete system to another or for a recovery from a comprehensive backup you can use this data to recreate your system.
You will need to secure off of the old system a combination of data. Effectively you will need:
Your ClearSDN registration information can move between systems fairly seemlessly. To move that information, consult the following to reset registration. It is important to note that you cannot assign a license to more than one box at a time. If you need to keep your old box in production, you can create a temporary evaluation license for your old box and move your license to your new box.
You will want to choose the option to reinstall the system that was previously registered in the setup wizard for ClearOS. You will also want to skip the app installation process and instead, install all the apps that you had before in the next section.
ClearOS will keep a list of installed apps in the following directory:
You will need this file but it will not be useful for you until you make some modifications:
mkdir -p /root/temponly/installedapps cp /var/clearos/configuration_backup/installed_apps.txt /root/temponly/installedapps/ grep -v core /root/temponly/installedapps/installed_apps.txt > /root/temponly/installedapps/restoreapp_list.txt
Copy this file, restoreapp_list.txt, to your new server. On the new server, create the following script after you register the system in the same temporary directory that you have the file:
mkdir -p /root/support/app-reinstall cd /root/support/app-reinstall
Make sure that the restore list is here:
Make this script as a file in this directorycalled recoverycommand.sh:
#!/bin/bash list=`cat /root/support/app-reinstall/restoreapp_list.txt` j=0 k=0 for i in $list; do let j++ done for l in $list; do let k++ if [ "$k" = "1" ]; then echo yum install $l \\ > /root/support/app-reinstall/app-restore.sh elif [ "$k" = "$j" ]; then echo $l >> /root/support/app-reinstall/app-restore.sh else echo $l \\ >> /root/support/app-reinstall/app-restore.sh fi done
Run this code:
/bin/bash < /root/support/app-reinstall/recoverycommand.sh
This will create the recovery command that will reinstall your apps. Run the following:
/bin/bash < /root/support/app-reinstall/app-restore.sh
Follow the prompts and install all of the apps that were previously installed on the other system.
From the old system, you will want to grab the most recent, good backup configuration data set. You can refer to this guide on how to use this tool. With the apps installed, you should be able to recover the configuration data. If you do not have access to Webconfig on the previous server, you can recover your data here:
On the Webconfig of the new server, restore this data from your workstation.
You will want to make sure that your new system is provisioned to make the most out of your disk space. To do this consult the Bind Mount guide to validate that you have space for your data. With the data restored, you can begin to recover your data. Pay special attention to the user and owner permissions. Depending on your back and recovery, permissions may not be what they need to be. If you are doing a direct recovery, these permissions will often be OK throughout.
Some common places where data might reside include:
It is vital and recommended that you take snapshots of databases while they are offline or by using the tools of the database (like mysqldump for mysql). These will ensure that the database is functional when migrated. Merely moving the data is usually not enough to avoid corruption.
Recovery of Third Party Apps may be beyond the recovery scope of this document but it is worth mentioning that there may be some components not covered under webconfig that were previously installed.