

By A Website Design
Hi, and welcome to the guide to successful backing-up and restoring of a Linux system!
Most of you have probably used Windows before you started using Ubuntu. During that time you might have needed to backup and restore your system. For Windows you would need proprietary software for which you would have to reboot your machine and boot into a special environment in which you could perform the backing-up/restoring (programs like Norton Ghost).
During that time you might have wondered why it wasn't possible to just add the whole c:\ to a big zip-file. This is impossible because in Windows, there are lots of files you can't copy or overwrite while they are being used, and therefore you needed specialized software to handle this.
Well, I'm here to tell you that those things, just like rebooting, are Windows CrazyThings (tm). There's no need to use programs like Ghost to create backups of your Ubuntu system (or any Linux system, for that matter). In fact; using Ghost might be a very bad idea if you are using anything but ext2. Ext3, the default Ubuntu partition, is seen by Ghost as a damaged ext2 partition and does a very good job at screwing up your data.
1: Backing-up
"What should I use to backup my system then?" might you ask. Easy; the same thing you use to backup/compress everything else; TAR. Unlike Windows, Linux doesn't restrict root access to anything, so you can just throw every single file on a partition in a TAR file!
To do this, become root with
sudo su
and go to the root of your filesystem (we use this in our example, but you can go anywhere you want your backup to end up, including remote or removable drives.)
cd /
Now, below is the full command I would use to make a backup of my system:
tar cvpzf backup.tgz --exclude=/proc --exclude=/lost+found --exclude=/backup.tgz --exclude=/mnt --exclude=/sys /
Now, lets explain this a little bit.
The 'tar' part is, obviously, the program we're going to use.
'cvpfz' are the options we give to tar, like 'create archive' (obviously),
'preserve permissions'(to keep the same permissions on everything the same), and 'gzip' to keep the size down.
Next, the name the archive is going to get. backup.tgz in our example.
Next comes the root of the directory we want to backup. Since we want to backup everything; /
Now come the directories we want to exclude. We don't want to backup everything since some dirs aren't very useful to include. Also make sure you don't include the file itself, or else you'll get weird results.
You might also not want to include the /mnt folder if you have other partitions mounted there or you'll end up backing those up too. Also make sure you don't have anything mounted in /media (i.e. don't have any cd's or removable media mounted). Either that or exclude /media.
Well, if the command agrees with you, hit enter (or return, whatever) and sit back&relax. This might take a while.
Afterwards you'll have a file called backup.tgz in the root of your files system, which is probably pretty large. Now you can burn it to DVD or move it to another machine, whatever you like!
NOTE:
At the end of the process you might get a message along the lines of 'tar: Error exit delayed from previous errors' or something, but in most cases you can just ignore that.
Alternatively, you can use Bzip2 to compress your backup. This means higher compression but lower speed. If compression is important to you, just substitute
the 'z' in the command with 'j', and give the backup the right extension.
That would make the command look like this:
tar cvpjf backup.tar.bz2 --exclude=/proc --exclude=/lost+found --exclude=/backup.tar.bz2 --exclude=/mnt --exclude=/sys /
2: Restoring
Warning: Please, for goodness sake, be careful here. If you don't understand what you are doing here you might end up overwriting stuff that is important to you, so please take care!
Well, we'll just continue with our example from the previous chapter; the file backup.tgz in the root of the partition.
Once again, make sure you are root and that you and the backup file are in the root of the filesystem.
One of the beautiful things of Linux is that This'll work even on a running system; no need to screw around with boot-cd's or anything. Of course, if you've rendered your system unbootable you might have no choice but to use a live-cd, but the results are the same. You can even remove every single file of a Linux system while it is running with one command. I'm not giving you that command though! ![]()
Well, back on-topic.
This is the command that I would use:
tar xvpfz backup.tgz -C /
Or if you used bz2;
tar xvpfj backup.tar.bz2 -C /
WARNING: this will overwrite every single file on your partition with the one in the archive!
Just hit enter/return/your brother/whatever and watch the fireworks. Again, this might take a while. When it is done, you have a fully restored Ubuntu system! Just make sure that, before you do anything else, you re-create the directories you excluded:
mkdir proc
mkdir lost+found
mkdir mnt
mkdir sys
etc...
And when you reboot, everything should be the way it was when you made the backup!
2.1: GRUB restore
Now, if you want to move your system to a new harddisk or if you did something nasty to your GRUB (like, say, install Windows), You'll also need to reinstall GRUB.
Restore GRUB quite simple in Ubuntu, instead going through all the "gain root access" and play with shell commands, you can use the Ubuntu installation CD to restore it without going through all kinds of hassles.
Here are the steps:
1. Boot your computer up with Ubunto CD
2. Go through all the process until you reech "[!!!] Disk Partition"
3. Select Manual Partition
4. Mount your appropriate linux partions
/
/boot
swap
.....
5. DO NOT FORMAT THEM.
6. Finish the manual partition
7. Say "Yes" when it asks you to save the changes
8. It will give you errors saying that "the system couldn't install ....." after that
9. Ignore them, keep select "continue" until you get back to the Ubuntu installation menu
10. Jump to "Install Grub ...."
11. Once it is finished, just restart your computer
Or this way is faster:
1. Pop in the Live CD, boot from it until you reach the desktop.
2. Open a terminal window or switch to a tty.
3. Type "grub"
4. Type "root (hd0,6)", or whatever your harddisk + boot partition numbers are (my /boot is at /dev/sda7, which translates to hd0,6 for grub).
5. Type "setup (hd0)", ot whatever your harddisk nr is.
6. Quit grub by typing "quit".
7. Reboot.
Just for Linux,
start a root terminal and enter the code:
sudo gedit /etc/fstab
Change the floppy line to read:
/dev/fd0 /media/floppy0 auto rw,user,noauto,sync 0 0
Open root Nautilus and go to:
File System; media
Now create a folder named:
floppy0
If you get an error stating:
mount: special device /dev/fd0 does not exist
Then run this code from terminal:
sudo modprobe floppy
The floppy drive should be listed
It's a known fact that more than half of all backups fail on recovery. As a result, I want something non-proprietary, works with any file system, is simple to use, and is pretty much guaranteed to work on all hardware. I also want to be sure that once backed up, my data is compressed using a very common data format (e.g., gzip). It would be a shame to use a proprietary tool that locks my data into some commercial proprietary format; I really hate that.
For the sake of this HOWTO, I'm going to assume you are familiar with "Linux on a CD" distributions like SystemRescueCD or Knoppix. Nothing personal, but if you aren't familiar with Linux, the command line, or how to use a Linux on a CD distro then this HOWTO is probably going to feel a bit over your head. BTW, this HOWTO assumes the drive you want to backup is at /dev/sda. Your block device DSF (device special file) might be different.
1 - Boot into Linux on a CD
Pop in your favorite Linux on a CD distro and boot your PC accordingly. For the sake of this HOWTO I'm going to assume you're using SystemRescueCD. However, any decent Linux on a CD distribution should have all of the tools you'll need.
2 - Figure Out Where to Place the Backup
Before you do anything further, you should figure out where you are going to place your backups. Backups are usually quite big, so expect them to chew up a good 80-100 GB of storage in most cases. The better compression you use when making the backup, the less storage space you'll need.
In my case, I decided to put the backup on a large RAID-1 (mirror) volume I have in my home datacenter. The mirror is attached to another Linux box, so I need to mount the mirror volume via Samba (you could use NFS too if you want):
rescuecd#/> mkdir /mirror
rescuecd#/> /sbin/mount.cifs //192.168.1.109/mark /mirror -ouser=mark
Once my mirror is mounted via Samba, I can read and write data to /mirror which will directly pipe it to the box connected to my RAID-1 volume.
3 - Determine the Appropriate Block Size
For a quicker backup, it can help to nail down the optimal block size of the disk device you are going to backup. Assuming you are going to backup /dev/sda, here's how you can use the fdisk command to determine the best block size:
rescuecd#/> echo "p" | /sbin/fdisk /dev/sda | grep Units
got EOF thrice - exiting..
Units = cylinders of 16065 * 512 = 8225280 bytes
Note the fdisk output says "cylinders of 16065 * 512". This means that there are 512 bytes per block on the disk. You can significantly improve the speed of the backup by increasing the block size by a multiple of 2 to 4. In this case, an optimal block size might be 1024 (512*2) or 2048 (512*4). BTW, getting greedy and using a block size of 5120 (512*10) or something excessive won't help; eventually the system will bottleneck at the device itself and you won't be able to squeeze out any additional performance from the backup process.
4 - Backup the Partition Layout
Before you do anything, it's always a good idea to backup the partition layout. When you create a whole disk backup, you don't have to worry about partitions. However, it can be handy to have this partition information (in case you need to mount a specific partition in the backup as a file using the exact offset). Use the sfdisk command to backup the partition layout:
rescuecd#/> sfdisk -d /dev/sda > /mirror/backup-sda.sf
Once you've backed up the partition layout, you can cat /mirror/backup-sda.sf to verify that you've correctly saved the partition mapping.
5 - Backup the Master Boot Record (MBR)
Again, you don't need to explicitly do this since a whole disk backup includes the MBR, but it's a good idea to snag the master boot record just in case. To backup the MBR, you can use the dd command:
rescuecd#/> dd if=/dev/sda of=/mirror/backup-sda.mbr count=1 bs=512
If you want to prove to yourself that you've successfully saved the MBR, you can run file /mirror/backup-sda.mbr to confirm you got what you needed ...
rescuecd#/> file /mirror/backup-sda.mbr
backup-sda.mbr: x86 boot sector; partition 2: ID=0x83, active, starthead 1, \
startsector 63, 2104452 sectors; partition 3: ID=0x82, starthead 0, \
startsector 2104515, 4192965 sectors, code offset 0x48
Yep, the file command confirmed that we've successfully snagged the MBR of the disk. The MBR always sits on the first 512k of any bootable disk.
6 - Run the Backup
Now that you've saved everything you need from the disk, it's time to make the backup. To create the backup, we'll use the dd command in conjunction with gzip (-9 for max compression). For dd, we'll use an optimal block size of 1024k (as determined in Step 3 of this HOWTO).
Warning, this will take a long time so it's probably best to let this run overnight. On my system at home, it took me 7+ hours to backup an entire 250 GB disk:
rescuecd#/> dd if=/dev/sda bs=1024kconv=noerror,sync| pv | \
gzip -c -9 > /mirror/backup-sda.gz
The conv=noerror,sync asks dd to keep going even if there are any read errors with the disk and to pad every input block with NULs to match your input block size. Note that I'm using the pv command to monitor the speed and progress of data flowing between dd and gzip. The pv command will tell me how much data I've processed, how long the backup has been running, and the approx speed of my backup; essentially it displays a progress bar on the console.
7 - Re-compress with P7ZIP (if desired)
Gzip offers pretty decent compression, but if you want insanely awesome compression, you can use P7ZIP to compress your backups. After the dd to gzip backup is complete in Step 6 above, you can re-compress backup-sda.gz using P7ZIP if you'd like to save a little storage space. If so, here's how:
rescuecd#/> gunzip -c /mirror/backup-sda.gz | 7za a /mirror/backup-sda.7z -si
Again, be warned, this process will seem like it takes forever. However, using P7ZIP over Gzip, saved me about 5 GB on the compressed backup. Using gzip -9 alone, I compressed a 250 GB backup image down to about 31 GB. With P7ZIP, the same backup was only 26 GB. P7ZIP is interesting because it sacrifices CPU cycles for compression, using a more exhaustive and complete compression algorithm. If you want more information on P7ZIP, check out Wikipedia's article on the 7z compression format.
8 - Restore from Backup
Backups are useless unless you can actually restore your data. If you need to restore a P7ZIP compressed backup to /dev/sda, here's how:
rescuecd#/> 7za x /mirror/backup-sda.7z -so | dd of=/dev/sda bs=1024k
If you decided to skip P7ZIP compression, and need to restore a Gzip compressed backup to /dev/sda, here's how:
rescuecd#/> gunzip -c /mirror/backup-sda.gz | dd of=/dev/sda bs=1024k
9 - Further Reading/Whatever
Some folks would say it's stupid not to use official backup tools like Partimage, Clonezilla, or Norton Ghost. To some extent, I agree with them. However ...
Why not use Partimage?
As of 5/26/09 Partimage claims NTFS support is experimental. So, if I want to backup a Windows box, I'm not going to leave my data with a tool that claims support for Windows file systems is experimental. I demand something more stable, and reliable.
Why not use Clonezilla?
I've never used Clonezilla, but it was recently recommned to me by an established IT professional. Perhaps I'll have to look into it. Assuming it dosen't lock my data into some god-awful proprietary format, maybe it will be a better solution that a raw dd disk backup.
What about Norton Ghost?
No way, Jose. Why pay for a commercial backup solution when everything you need to archive your system is available for free? But I guess if you care about support, and data warranties, then yes a commerical solution might be right for you.
All this talk of Linux, what about HP-UX?
Basically, all of the same concepts apply. However, if you're running HP-UX you can use HP's DRD (Dynamic Root Disk) clone feature to create an exact copy of an active system disk.
This tutorial will show how to set samba to allow read-only file sharing for your LAN computers as guest (without be prompted for a password).
Because users won't be prompted for a user/password, this tutorial is meant to be installed in a LAN where all host are to be trusted.
There is many advantages of sharing files in a LAN. For instance, when you have a multimedia box (playing music, movies....) it is great to be able to access the music on that box from any machines in your LAN.
Let's get started. In the first place, you need to have samba installed.
$sudo apt-get install samba

Because we are going to make samba security insecure, make sure only your local network can access samba service. To do so, open and edit /etc/samba/smb.conf
$sudo vi /etc/samba/smb.conf
and set interfaces to lo and your local network interface. In my case: eth1.
interfaces = lo eth1
bind interfaces only = true
Now, it is time to smoothen samba default security by changing the security variable: security and make sure it is set to share instead of user and that guest account is enabled:
security = share
...
...
guest account = nobody
Now, we can create a share to be accessible to guest users:
[Guest Share]
comment = Guest access share
path = /path/to/dir/to/share
browseable = yes
read only = yes
guest ok = yes
You can now test that your configuration is good using testparm:
$ testparm
If everything is fine, it is time to reload samba service to have your new configuration taken into account:
$sudo /etc/init.d/samba reload
That's it, anybody in your LAN can now access your share.