Howto: Backup and restore your system!

[Green_Star]

I figure why not since it will fit on one. Perhaps give it to someone else in case something terrible were to happen. However, if something THAT bad were to happen, getting my computer back up and running is probably the last thing on my mind.

More so though, I just love the fact that it will fit on one DVD.

I am not sure how frequent you do backup. I made a script, it will backup every week to my other drive using cron and give that backup name as backup-'date'.tgz and delete the old backups which are older than two weeks, i.e., at any time I will have two previous backups.

[escapedturkey]

What'd be nice to do is:

Hook up USB stick - Reboot - Grub - boots to a clonezilla install - runs a script that creates image and copies to USB stick - when finished reboots to Ubuntu.

Is that possible?

[Green_Star]

I never heard of clonezilla, I just googled it, looks like it makes a disk/partition copy. Thanks for letting me know about that product.

I think you may have to write a script in clonezilla to make a image of your required disk directly to your flash drive, and reboot after the process.

To boot directly from USB you may have to change your BOIS boot sequence. Even though if you are not at the computer when it is rebooting after the process then it will boot again to your USB.

As of now, I can say that you can not automate the process, it requires some manual work.

OR

1. Install clonezilla into one of your usb.

IN UBUNTU

1. Make a copy of your menu.list as menu.clonezilla
2. Modify the menu.clonezilla so that there is only one entry that will boot directly into your clonezilla
3. Create a script, it will move your menu.list to menu.backup and menu.clonezilla to menu.list, then it reboots the system.
4. Make sure this script runs as root
5. Schedule this script using corn

In CLONEZILLA

1. Make a script to create a disk image into your USB, after this process it will move the ubuntu partition menu.list to menu.clonezilla and menu.backup to menu.list, reboot the system.

I am not sure how we can make an GRUB entry so that it will boot from USB. The problem with this method is, when this ubuntu schedule kicks in the USB drive should be plugged in. And if some reason machine is not able to boot from USB then you may have to restore your GRUB with some other methods. So instead of loading clonezilla into your USB I guess it is better to install in any other drive available which is not going to backup by clonezilla. Because I think clonezilla wants the disk should be unmounted before making a clone, so that means if you want to clone a disk from where clonezilla is booted then it may not possible. Check with clonezilla documentation.

What'd be nice to do is:

Hook up USB stick - Reboot - Grub - boots to a clonezilla install - runs a script that creates image and copies to USB stick - when finished reboots to Ubuntu.

Is that possible?

[escapedturkey]

I was thinking more along the lines of if you could install CloneZilla in a partition on the HD, then hook up a USB stick or insert a writeable cd/dvd, reboot, Grub, it boots CloneZilla off your HD, than a script automatically creates image, copies, and reboots. Would that be easier?

[lmicu]

Hi, and welcome to the Heliode 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.

EDIT : kvidell suggests below we also exclude the /dev directory. I have other evidence that says it is very unwise to do so though.

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 filessytem, which is probably pretty large. Now you can burn it to DVD or move it to another machine, whatever you like!

EDIT2:
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.
There are several very good howto's on how to do that here on this forum, so i'm not going to reinvent the wheel. Instead, take a look here:

http://www.ubuntuforums.org/showthre...t=grub+restore

There are a couple of methods proposed. I personally recommend the second one, posted by remmelt, since that has always worked for me.


Well that's it! I hope it was helpful!
As always, any feedback is appreciated!

I followed the instructions here and I also excluded the /dev. I was backing up on a external hard drive and I received an error like this:

bzip2: I/O or other error, bailing out. Possible reason follows.
bzip2: No space left on device
Input file = (stdin), output file = (stdout)
root@lucian-laptop:/media/My Book#

is this normal, I think that there were more things to back up, my backup file is only 6 G, it should be around 20 or more, space is not an issue I have around 300 free on this hdd

thanks

[escapedturkey]

Can any of this be done with rsync -- to a usb stick, dvd, or remote server?

[steveydoteu]

I would suggest using rsync with cron jobs, but it is indeed possible, as this howto is only aiding you in creating the back up files which can then be moved to a remote location.

You would need a script to create the back up, and one to use rsync for uploading/moving. Although they could probably be combined. This then needs to be passed to cron in the form of a cron job.

My knowledge of cron/rsync is limited though, so I could be totally wrong.

[commonplace]

Great tutorial. Due to disk space constraints, I needed to export the tar to an external drive that is fat32 formated. If this hasn't been posted already, thought I would share how to get around the 4GB size restraint using the split command.

If you take Heliode's command and alter it like this

 tar cvpzf - --exclude=/proc --exclude=/lost+found --exclude=/backup.tgz --exclude=/mnt  --exclude=/media --exclude=/sys / | split -a 2 -b 2000m - /media/ieee1394disk/backup.tgz

It will create your backup.tar in 2000MB chunks at /media/ieee1394/

Restore like

gzcat /media/ieee1394disk/backup.tgz* | tar xvpfz - -C /

I've done the backup portion using this, but haven't actually tested a restore. So use at your own risk

The gzcat command isn't on my system (Ubuntu 8.10) and I can't find it in the repos. Can I use gunzip somehow, or how do I get gzcat? I've got my backup but no way to restore it at the moment.

Edit: Figured out gzcat is the same as gunzip -c

/Kevin

[brandroid]

I'm not sure if this has been asked (or what to search for if it has), so just point me to the answer if it's already out there: I want to backup my existing Ubuntu 8.1 installation and save it on my ex-HD. Then I want to install Ubuntu on a virtual machine (under WinXP), and take the data I backed up and restore it there.

Is it possible? Are there other steps I should do?

Sort of second question: Would backing up just home do what I need? My biggest worry is losing my programs/settings/etc and having to go through and install (and set them up) all over again.

Thanks in advance for any help.

[gnome_mm]

Sort of second question: Would backing up just home do what I need? My biggest worry is losing my programs/settings/etc and having to go through and install (and set them up) all over again.

Concerning your second question:
As a user, the only directory you have write access to is your home directory (apart from some other directories such as /tmp, removable drives under /media and so on). And since you will most likely execute your programs as a user (and not root), the settings of that program can only be saved in your home directory, e.g. .gimp, .mplayer and so on. Even your panel and gnome-specific settings are saved there, e.g. in .gnome2. This is the reason why it is often regarded sufficient to backup your home partition and do a fresh install of your system to keep your settings and files.

However, be advised that this might not hold true if a different release of Ubuntu is installed as some programs and both the way they store their settings (xml instead of a simple text file) and the location where they are stored (e.g. liferea --> liferea_1.4) might have gone through a major change.

Keeping your home directory along with a list of installed packages (e.g. have synaptic spit out a text file with all your packages and use that in a single apt-get command) should often be sufficient as a backup solution if you didn't mess around as root too much.

For convenience though, you can create a first backup of your system using the offered solution.

Now that I think about it. Can't you just install Ubuntu on your VM, copy over your home directory and install whatever package was left out during the installation by using the log created from synaptic? This way, you keep both your programs and settings.

Regards

EDIT: Thanks for the useful hints in this thread. For my personal needs, I prefer the TAR backup solution over all others that are available. There is, however, a disadvantage to it and it has been pointed out in this thread several times: files are only overwritten and none of the additional files created after the last backup are deleted. Shouldn't it be simply
a) boot from a live CD,
b) mount the partitions to be restored,
c) wipe everything on those partitions (via the useful rm -rf#*!§$ you know and
d) just extract the tar backup to the mounted partition
to overcome this disadvantage? Or am I missing an important point here?

At the moment, I can't test this idea, so I would be grateful if someone could post their procedure or a few hints on this and why it might or might not work.