Bootable Cloned Backup

[oldwierdal]

I'd like to show you my bootable modified clone system backup. We all know the importance of keeping regular backups of our system. This version of a backup will not only allow you to restore your system. It is a bootable copy of your system, kept on a separate hard drive, or even on an external hard drive. In this way, you boot to your system, and copy it back onto a new hard drive within 30 minutes or much less, depending on whether you need to partition and format your replacement drive.
By writing your MBR to both hard drives as well as to a usb thumb-drive, in the event of a failure of your main hard drive or even the failure of your mother board, by changing the boot order in CMOS, you will most often be able to boot to your backup drive and restore your system rather quickly. Occasionally, though, you might have to use a rescue disk, such as a Debian installation disk to write the MBR to a suitable drive.
I will cover 'grub-install' later on.

Requirements;
1. A second hard drive, internal or external, large enough to contain all of your system files, and at least a mountable /home/user partition.
2. A partitioning program of your choice. I use gparted. But any program capable of partitioning and formatting drives will do.
3. Setting up the appropriate mount points and making the appropriate entries in your /etc/fstab file.
4. A working knowledge of editing files, and a working knowledge of what those files are supposed to do.
5. A working knowledge of writing a 'bash' script file. I will cover the basics, but a good investment would be “Linux Command Line and Shell Scripting” by Blum/Bresnahan, a Wiley publication. Just google the title, and you'll find where to get a copy.
6. And last, the easiest one to lapse and forget about..... the discipline to keep your backup current and often, and to test the functionality of your finished product at the end of every backup session.

My system; (Yours will probably be different, but the principles are the same regardless of your hardware.)
1. I have two 750 G internal hard drives which I have partitioned similarly, although not identically. They don't really need to be identical.
2. I have a directory in the root directory called “/bkup” and another called “/bkup-home, as well as one named /purge, and another named /save.”
3. code: sudo mkdir /bkup
sudo mkdir /bkup-home
sudo mkdir /purge
sudo mkdir /save
The '/purge' and '/save' directories won't be used as mount points, but will be used to save a copy of the '/bkup/etc/fstab' file and others which you might deem necessary at the start of every backup, and to restore it at the conclusion of every backup, and to purge your backup of older files in preparation of copying new ones. The choice to delete rather that to append is debatable. I have found that occasionally newer copies of files can cause unforseen problems in the future when written over older existing files. Just as easy for me, and much safer, to simply delete the old files, and copy the newer ones over.
4. With your favorite text editor, make the following entries in your /etc/fstab file. I have copied my /etc/fstab here, and the bold entries reflect the entries required in yours. You will need to know the UUID of all your partitions, so first, open a terminal and type;
al@uglybox:~$ sudo blkid
[sudo] password for al:
/dev/sda1: LABEL="418a1" UUID="920c5e8f-7b2e-4efb-8ef9-b8cd4aa0b393" TYPE="ext4"
/dev/sda2: LABEL="418a2" UUID="8ef0860e-2608-4c51-956e-dc56a7d8f514" TYPE="ext4"
/dev/sda3: UUID="fc40e0d7-b5d7-4817-8dd8-8a7979030a76" TYPE="swap"
/dev/sdc1: LABEL="640a1" UUID="5bb1888a-92f0-4693-a8c6-6b98cbe13712" TYPE="ext4"
/dev/sdc2: LABEL="640a2" UUID="d1550dfb-6ec0-4764-b3af-8ff4cde2bd6f" TYPE="ext4"
/dev/sdc4: LABEL="640a3" UUID="33f36362-8d9c-42a6-9e66-0fd88346c92d" TYPE="swap"
/dev/sdb1: UUID="bfa57166-d21c-448b-9343-1bbe31d81fa4" TYPE="swap"
/dev/sdb2: LABEL="528a2" UUID="e4dace90-bcd2-4d42-b325-3cde84752476" TYPE="ext4"
/dev/sdb3: LABEL="528a3" UUID="e0859c74-71df-4017-92ee-8d19b44186e8" TYPE="ext4"
/dev/sde1: LABEL="USB DISK" UUID="2468-3132" TYPE="vfat"

My backup drive is /dev/sdc1: LABEL="640a1" UUID="5bb1888a-92f0-4693-a8c6-6b98cbe13712" TYPE="ext4" for my '/' partition,
and /dev/sdc2: LABEL="640a2" UUID="d1550dfb-6ec0-4764-b3af-8ff4cde2bd6f" TYPE="ext4" for my /home partition. It is important to note that the 'dev/sd*' might very well change from boot to boot. Using the UUID is a much more reliable means of identifying your partitions. Using LABEL will also work, but is still not as secure, nor reliable as UUID in my opinion. I also recommend using “ noauto,user,exec” so that the drive/partition is only mounted when you choose. That is my personal preference, but you might wish to have it auto mounted. In that case, omit the 'noauto.' The following entries in my /etc/fstab which are bold are the entries you will need to make.

al@uglybox:~$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'vol_id --uuid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# / was on UUID=e4dace90-bcd2-4d42-b325-3cde84752476 during installation
UUID=e4dace90-bcd2-4d42-b325-3cde84752476 / ext4 relatime,errors=remount-ro 0 1

# /home was on UUID=e0859c74-71df-4017-92ee-8d19b44186e8 during installation
UUID=e0859c74-71df-4017-92ee-8d19b44186e8 /home ext4 relatime 0 2

# /bkup was on UUID=5bb1888a-92f0-4693-a8c6-6b98cbe13712 as a cloned backup of / during installation
UUID=5bb1888a-92f0-4693-a8c6-6b98cbe13712 /bkup ext4 noauto,user,exec 1 2

# /bkup-home was on UUID=d1550dfb-6ec0-4764-b3af-8ff4cde2bd6f as a cloned backup of /home during installation
UUID=d1550dfb-6ec0-4764-b3af-8ff4cde2bd6f /bkup-home ext4 noauto,user,exec 1 2

# /qiana was on UUID=920c5e8f-7b2e-4efb-8ef9-b8cd4aa0b393 during installation.
UUID=920c5e8f-7b2e-4efb-8ef9-b8cd4aa0b393 /qiana ext4 noauto,user,exec 1 2

# /qiana-home was on UUID=8ef0860e-2608-4c51-956e-dc56a7d8f514 during installation.
UUID=8ef0860e-2608-4c51-956e-dc56a7d8f514 /qiana-home ext4 noauto,user,exec 1 2

# /usb was on UUID=2468-3132 during installation
UUID=2468-3132 /usb vfat noauto,user,exec 1 2

# swap was on UUID=bfa57166-d21c-448b-9343-1bbe31d81fa4 during installation
UUID=bfa57166-d21c-448b-9343-1bbe31d81fa4 none swap sw 0 0

5. Mount /bkup;
al@uglybox:~$ mount /bkup (If your entries are correct in /etc/fstab, /bkup should mount without any error messages. If not, follow the error message, and make the necessary corrections to either your /etc/fstab file, or to your directory entries in your '/' directory.)

al@uglybox:~$ sudo mkdir /bkup/home
al@uglybox:~$ sudo mkdir /bkup/proc
al@uglybox:~$ sudo mkdir /bkup/purge
al@uglybox:~$ sudo mkdir /bkup/save
al@uglybox:~$ sudo mkdir /bkup/sys

Now, the drive '/bkup' is ready to receive it's initial backup of your system. You can't copy active and dynamic files such as those in /proc and /sys, and /home is mounted on a separate drive, which is why we simply made those directories, but we will not be copying anything into them. They will be needed and used once we boot into the backup of our system. So, for now we will just copy all of the files and directories which are not active and dynamic;

al@uglybox:~$sudo rsync -avz /* /bkup --exclude={/bkup,/bkup-home,/cdrom,/home,/lost+found,/media,/mnt,/proc,/purge,/qiana,/qiana-home,/save,/sys,/usb}

6. Edit /bkup/etc/fstab to reflect the correct UUID's and mount points, else you'll just boot to your original system, and not the backup; (Note the bold entries are those which you will need to edit to reflect the correct UUID's)

al@uglybox:~$ cat /bkup/etc/fstab
# /etc/fstab: static file system information.
#
# Use 'vol_id --uuid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# / was on UUID=5bb1888a-92f0-4693-a8c6-6b98cbe13712 as a cloned backup of 'maya/' during installation
UUID=5bb1888a-92f0-4693-a8c6-6b98cbe13712 / ext4 relatime,errors=remount-ro 0 1

# /home was on UUID=d1550dfb-6ec0-4764-b3af-8ff4cde2bd6f as a cloned backup of 'maya-home' during installation
UUID=d1550dfb-6ec0-4764-b3af-8ff4cde2bd6f /home ext4 relatime 0 2

# /maya was on UUID=e4dace90-bcd2-4d42-b325-3cde84752476 during installation
UUID=e4dace90-bcd2-4d42-b325-3cde84752476 /maya ext4 noauto,user,exec 1 2

# /maya-home was on UUID=e0859c74-71df-4017-92ee-8d19b44186e8 during installation
UUID=e0859c74-71df-4017-92ee-8d19b44186e8 /maya-home ext4 noauto,user,exec 1 2

# /qiana was on UUID=920c5e8f-7b2e-4efb-8ef9-b8cd4aa0b393 during installation.
UUID=920c5e8f-7b2e-4efb-8ef9-b8cd4aa0b393 /qiana ext4 noauto,user,exec1 2

# /qiana-home was on UUID=8ef0860e-2608-4c51-956e-dc56a7d8f514 during installation.
UUID=8ef0860e-2608-4c51-956e-dc56a7d8f514 /qiana-home ext4 noauto,user,exec 1 2

# /usb was on UUID=2468-3132 during installation
UUID=2468-3132 /usb vfat noauto,user,exec 1 2

# swap was on UUID=33f36362-8d9c-42a6-9e66-0fd88346c92d during installation
UUID=33f36362-8d9c-42a6-9e66-0fd88346c92d none swap sw 0 0

And, now the script to backup the /home/user directory;
al@uglybox:~/bin$ cat bkup-home
#!/bin/bash
# This script will perform a backup of the home directory. There are scripts which I do not want to run if the backup is booted and run, so they are excluded from the backup, and to doubley insure they are not run, the bin directory is copied before backup to a 'save' directory, and copied back after the backup is run.

mount /bkup-home
cp -ravd /bkup-home/al/bin /bkup-home/save
rsync -avz /home/al/* /bkup-home/al --exclude={/home/al/bin}
cp -ravd /bkup-home/save/bin /bkup-home/al/
umount /bkup-home

7. Edit /boot/grub/menu.lst and make a new entry for your Backup. ( I use Grub Legacy. There are those who prefer, insist, even, to use Grub2. My experience has not been happy using Grub2. So, this is written for Grub Legacy. Perhaps someone might like to tinker with Grub2 and come up with an alternative to mine. I wouldn't have any problem with that. I just prefer Grub legacy.) The entry in bold is my backup entry.
al@uglybox:~$ cat /boot/grub/menu.lst

color cyan/blue white/blue
splashimage=(hd0,1)/boot/grub/splashimages/Lake_mapourika_NZ.xpm.gz
timeout 5
default 0
# hiddenmenu

title Linux Mint 13 LTS w/Mate` 1.6 64bit "Maya" (kernel 3.2.0-61-generic)
root (hd0,1)
kernel /boot/vmlinuz-3.2.0-61-generic root=UUID=e4dace90-bcd2-4d42-b325-3cde84752476 ro quiet splash
initrd /boot/initrd.img-3.2.0-61-generic
quiet

title Cloned Backup of Linux Mint 13 LTS w/Mate` 1.6 64bit "Maya" (kernel 3.2.0-61-generic)
root (hd1,0)
kernel /boot/vmlinuz-3.2.0-61-generic root=UUID=5bb1888a-92f0-4693-a8c6-6b98cbe13712 ro quiet splash
initrd /boot/initrd.img-3.2.0-61-generic
quiet

title Testing Linux Mint 17 LTS w/Mate` 1.8 64bit "Qiana" (kernel 3.13.0-24-generic)
root (hd2,0)
kernel /boot/vmlinuz-3.13.0-24-generic root=UUID=920c5e8f-7b2e-4efb-8ef9-b8cd4aa0b393 ro quiet splash
initrd /boot/initrd.img-3.13.0-24-generic
quiet

Now, install grub onto each possible drive, including usb drives;

al@uglybox:~$ sudo grub-install --recheck /dev/sda
[sudo] password for al:
Probing devices to guess BIOS drives. This may take a long time.
Searching for GRUB installation directory ... found: /boot/grub
Installing GRUB to /dev/sda as (hd0)...
Installation finished. No error reported.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.

(fd0) /dev/fd0
(hd0) /dev/sda
(hd1) /dev/sdb
(hd2) /dev/sdc
(hd3) /dev/sde

Repeat grub-install for each of the remaining drives listed, e.g. /dev/sdb, /dev/sdc, and /dev/sde. This will insure that you can boot from any and all drives your bios will recognize. You may have to tinker with your bios to allow booting from all of your available drives, and which you feel is the best boot order.

I wrote a script which I use to automate the backup. I then use gnome- schedule as root to set a recurring time to perform the backup. Below is my script.

al@uglybox:~$ sudo # cat bksys
#!/bin/bash
# This script will perform a bootable system backup on a separate hard drive.
umount /bkup-home
umount /qiana-home
umount /usb
mount /bkup
cp /bkup/etc/fstab /bkup/save/fstab.bkup.save
cp /bkup/etc/modprobe.d/blacklist.conf /bkup/save/blacklist.conf
cp /bkup/boot/grub/menu.lst /bkup/save/menu.lst.save
rsync -avz /* /bkup --exclude={/bkup,/bkup-home,/cdrom,/home,/lost+found,/media,/mnt,/proc,/purge,/qiana,/qiana-home,/save,/sys,/usb}
cp /bkup/save/fstab.bkup.save /bkup/etc/fstab
cp /bkup/save/blacklist.conf.disable-k10 /bkup/etc/modprobe.d/blacklist.conf
cp /bkup/save/menu.lst.save /bkup/boot/grub/menu.lst
umount /bkup
mount /bkup-home
mount /qiana-home
mount /usb

This script will perform an update to the backup you already have. So, obviously, we will need to make the initial backup first. So, now we test it. Reboot, and scroll down to the Backup entry. If we haven't made any mistakes when editing our /etc/fstab and /boot/grub/menu.lst files, we should boot into the Cloned Backup of our system. The System Monitor should show which file systems are mounted. Else just type;
$ mount -l <enter> and the results should show the correctly mounted partitions.

I also have a script which will restore your system from your backup drive onto your primary drive. It was written with the assumption that the original /etc/fstab file and the /boot/grub/menu.lst file are present. If so, this script will have you completely restored in just a few minutes. If not, you will have to edit the /etc/fstab and /boot/grub/menu.lst files for your primary drive accordingly before you attempt to reboot into your primary drive, else you'll just boot back into your backup drive. Below is my restoresys script;

al@uglybox:~$ sudo cat /root/bin/restoresys
[sudo] password for al:
#!/bin/bash
# This script will perform a complete system restore from a cloned and bootable system backup on a separate hard drive.
mount /maya
cp /maya/etc/fstab /maya/save/fstab.maya.save
cp /maya/boot/grub/menu.lst /maya/save/
cp /maya/etc/modprobe.d/blacklist.conf /maya/save/blacklist.conf
mv /maya/bin /maya/purge
mv /maya/boot /maya/purge
mv /maya/dev /maya/purge
mv /maya/etc /maya/purge
mv /maya/i* /maya/purge
mv /maya/lib* /maya/purge
mv /maya/opt /maya/purge
mv /maya/root /maya/purge
mv /maya/run /maya/purge
mv /maya/sbin /maya/purge
mv /maya/tmp /maya/purge
mv /maya/usr /maya/purge
mv /maya/v* /maya/purge
rm -rfv /maya/purge/*
rsync -avz /* /bkup --exclude={/bkup,/bkup-home,/cdrom,/home,/lost+found,/media,/mnt,/proc,/purge,/qiana,/qiana-home,/save,/sys,/usb}
cp /maya/save/fstab.maya.save /maya/etc/fstab
cp /maya/save/menu.lst /maya/boot/grub
cp /maya/save/blacklist.conf /maya/etc/modprobe.d/blacklist.conf
umount /maya

I suppose it goes without saying that if you are recovering from a total system failure onto a new hard drive, the new drive must first be properly partitioned, and it won't be necessary to move anything to the new drive /purge directory, as it wouldn't even exist. Just edit the restoresys script so that all you'll be doing is copying your backup system onto your new drive. That can be done by just inserting a '#' symbol before each line until you get to the 'rsync' line from your backup to your new drive.

Suggestions, improvements, and comments are all welcome.

Thanks,
owa

[MartyMint]

If you already have two hard drives, wouldn't RAID 1 be easier?

[kukamuumuka]

The easy way is to use RSync. An example:

Code: Select all

sudo rsync -avz –exclude={/proc,/mnt,/media,/dev,/sys,/tmp,/lost+found} // /path/destination
sudo mkdir /path/destination/proc
sudo mkdir /path/destination/media
sudo mkdir /path/destination/dev
sudo mkdir /path/destination/sys
sudo mkdir /path/destination/tmp
sudo mkdir /path/destination/mnt

Grub can install via live DVD/USB, or to use boot-CD for booting and install grub via backuped system.

[oldwierdal]

The problem with either RAID or rsync is that, in order for your backup drive to boot to the backup drive, you will still need to either save the /target/etc/fstab on the target, and then copy it back to /target/etc/fstab, or edit the /target/etc/fstab appropriately afterwards to reflect the new UUID's.
In truth, I have not tried using rsync yet. It has just been recently that I retired and have more time to play with things. I will try to make some time to play with rsync and/or RAID.
Meanwhile, this method has been working for me quite well for a few years. Just thought I'd share it.

Thanks,
owa

[oldwierdal]

I've been playing a bit with using rsync instead of all the individual cp* commands in my script. The example shown by administrollaattori didn't quite work as desired. This is what I ended up with that actually works, as far as I can tell, so far.
# cat testbksys
#!/bin/bash
# This script will perform a bootable system backup on a separate hard drive.
umount /bkup-home
umount /qiana-home
umount /usb
mount /bkup
cp /bkup/etc/fstab /bkup/save/fstab.bkup.save
cp /bkup/etc/modprobe.d/blacklist.conf /bkup/save/blacklist.conf
cp /bkup/boot/grub/menu.lst /bkup/save/menu.lst.save
rsync -avz /* /bkup --exclude={/bkup,/bkup-home,/cdrom,/home,/lost+found,/media,/mnt,/proc,/purge,/qiana,/qiana-home,/save,/sys,/usb}
cp /bkup/save/fstab.bkup.save /bkup/etc/fstab
cp /bkup/save/blacklist.conf.disable-k10 /bkup/etc/modprobe.d/blacklist.conf
cp /bkup/save/menu.lst.save /bkup/boot/grub/menu.lst
umount /bkup
mount /bkup-home
mount /qiana-home
mount /usb

And this was the output after a successful run;

# ./testbksys
umount: /usb: not mounted
sending incremental file list
boot/grub/menu.lst
etc/
etc/fstab
etc/mtab
etc/modprobe.d/blacklist.conf
root/.cache/dconf/
root/.config/dconf/
root/.config/dconf/user
root/.config/gedit/accels
root/.local/share/
root/.local/share/recently-used.xbel
root/.local/share/zeitgeist/activity.sqlite-shm
root/.local/share/zeitgeist/activity.sqlite-wal
root/.local/share/zeitgeist/fts.index/
root/.local/share/zeitgeist/fts.index/position.DB
root/.local/share/zeitgeist/fts.index/position.baseA
root/.local/share/zeitgeist/fts.index/position.baseB
root/.local/share/zeitgeist/fts.index/postlist.DB
root/.local/share/zeitgeist/fts.index/postlist.baseA
root/.local/share/zeitgeist/fts.index/postlist.baseB
root/.local/share/zeitgeist/fts.index/record.DB
root/.local/share/zeitgeist/fts.index/record.baseA
root/.local/share/zeitgeist/fts.index/record.baseB
root/.local/share/zeitgeist/fts.index/termlist.DB
root/.local/share/zeitgeist/fts.index/termlist.baseA
root/.local/share/zeitgeist/fts.index/termlist.baseB
root/bin/
root/bin/testbksys
root/bin/testbksys~
var/log/kern.log
var/log/syslog

sent 6999993 bytes received 23173 bytes 286659.84 bytes/sec
total size is 6446900535 speedup is 917.95

I then checked the critical /bkup/etc/fstab file to make sure that my backup would still boot to the correct drive, and the /bkup/etc/fstab is correct. Now, for the real test..... I'll reboot to the backup and post back with the results.
Thanks for prodding me to explore rsync.

owa

[oldwierdal]

Success!! I rebooted to the cloned backup and everything works. So, I edited the original post to use 'rsync' instead of all the 'cp *' stuff.
Thanks to administrollaattori for prodding my to study up on 'rsync.'
Not only can old dogs learn new tricks, so, also, can old farts learn new tricks!!

Still, this bootable clone backup system has saved me hours of time and frustration recovering from misshaps, such as software failures, hard drive failures, and even a failed mobo! I hope some can find it useful.....perhaps even more useful now, using rsync.

Thanks again,

owa

[usbtux]

You can use clonezilla for the same process - you can also use clonezilla to install a virtualbox install thet will work when cloned to a internal/external harddrive or flash drive http://www.youtube.com/watch?v=hPA2iAShTVU

[austin.texas]

I cloned a few bootable partitions last week.
Copy 15GB Mint 16 partition with gparted on live DVD
Paste into unallocated space on a different drive with gparted
Assign new UUID with gparted
Edit /etc/fstab with gedit on live DVD
Boot into Mint 17 and update GRUB to put new Mint 16 on the GRUB menu
DONE...
Without Mint 17 I would have booted into the new Mint 16 with my SuperGrub2 CD, and then installed GRUB to the MBR.

[oldwierdal]

Thanks for the tips about clonezilla...... another toy for me to play with. My wife will be sooooo happy!

owa