Complete Backup and Restore Using “tar” Command
We’ve all made mistakes during our configuration and at some point wish we could go back in time before the mistake. Now that you have the ultimate setup that you’ve worked so hard on, how are you going to be sure you have the same setup after a system or hard drive crash? I’ll explain methods I use to maintain my setup and configuration files without the loss of any data or personal settings. Once you have recovered from the crash, the restoration can be as simple as typing a single command using the Live CD and a terminal.
The first, and most important, is that the backup medium is not located on the same drive as your Linux setup. I personally use an external USB drive for all my backup data (which can be purchased for next to nothing nowadays), although you could use another remote drive within your system unit, even a non bootable drive. These techniques are based on my favorite flavor Ubuntu and can be applied to any version of GNU/Linux.
The easiest method would be to use a simple “tar” command (such as):
Flags used by the “tar” command aid in the backup procedure by allowing us to include or exclude files or directories. With the “exclude” flag we can exclude system folders or individual files which are not necessary for the backup and can be recreated after the restore procedure (as I’ve demonstrated below). This is just a simple backup using the “tar” command but can be included in a more sophisticated approach.
Restoring the above backup procedure is as simple as becoming “root” (sudo su) going to “/” (root) and typing on a command line:
WARNING!! This will overwrite every single file on your partition with the one in the backup archive!
To complete the restore just create the directories that you excluded in the above backup command using the “exclude” flag :
By using the “tar” command to backup your data, you have the ability to extract any file or directory out of the “backup.tgz” file for recovery, for instance, if you have a corrupt or mis-configured “fstab” file you want to recover, you could simply issue the command:
If your in the “/” root directory this will extract the “/etc/fstab” file to the original location. A far safer solution is to restore the desired files under a different directory (for example, your home directory), and then compare, move, or update the files to their original locations afterward. This works the same with complete directories as well.
In conclusion:
By using the method described above you can backup and restore a basic Linux install. We can use this method to give us a more sophisticated backup scheme by using a bash script and a few other backup details. Watch for upcoming write-ups explaining how we can save all configuration, system information, MBR and complete backup using such a scheme. No matter how complex your system, I find the “tar” procedure to be the most widely used and most reliable for any backup solution.
Loading ...
I prefer using a rsync based backup system.
Binny: Cool, why don’t you do a how-to then instead of just leaving a rather useless comment?
thanks!
@Kiro: Hah! If you’d bothered to follow the link in Binny’s comment, you’d have found his how-to on backing up with rsync. Your comment was rather useless…
Thanks Robert + Binny (but not Kiro…)
LOL. Kiro is a jerk…
Amazing! Thanks ;)
rsync and tar are different backup solutions. Anyway I have also published a howto
about rsyn whihch also includes a GUI tool, grsync, for those who don’t like the
terminal way!
[url=http://www.my-guides.net/en/content/view/87/26/]How to backup/synchronize your files using rsync[/url]
Try remastersys! Creates an ISO file so that you can burn your own system as a linux livre CD, Works like a charm!
Follow: http://www.remastersys.klikit-linux.com/
Cheers!
With GNU tar, you can use the “–one-file-system” option to avoid most of those tedious “–exclude” options, since they’re separately mounted file systems. Since the mount points have to exist, those dirs have to exist and so should be backed up, so that you don’t have to create the mount points before restoring. If your /home and /boot dirs are on separate filesystems, you’d have to back them up separately as well then (which I see as an advantage, since your backup would preserve your partition structure).
Also, the “p” option isn’t necessary when creating the archive. When restoring the backup, you’d typically be root, so the “p” option is superfluous then as well.
I haven’t tried this all yet, though. I’ve just been using sbackupd via the Ubuntu GUI, which I believe is a tar wrapper.
To be honest, automatically scheduled backups are almost a necessity, since it takes way too much self-discipline to consistently backup your system every week (say). But then you have to create a script that is run by cron, which is too much effort for most people, and they’ll probably screw it up even if they try. Ubuntu’s SBackup has scheduling and deletion (of old backups) built in, and is passable, sort of.
You see, for me, scheduled backup on GNU/Linux is still a problem because something always seems to get in the way. For example, I can’t guarantee that my laptop won’t suspend/sleep midway through a long backup. I’m forced to leave my external USB hard drive, which is my backup destination, on at all times; it doesn’t power down / sleep gracefully or even spin down. Not only is there a constant sound from the drive, there’s a danger that a month later, with drive still on, I might accidentally shove the drive since it’s on the desk with all my other junk. And then there’s the issue of off-site backups: the need to rotate hard drives. Oh, and there seems to be an intermittent bug in USB support on my Thinkpad x60 that leads to some crashes when the machine comes out of sleep. Of course one has to ensure that the machine is out of sleep for the backup to initiate. Getting all this right so that you don’t have to think about it again is a bloody nightmare. And it’s been on my to-do list for like, um, a decade. It’s embarassing how much time is needed hunting down a reliable solution.
In sum, real, reliable, automated backup requires an infrastructure or ecosystem of disparate requirements that is really easy to screw up. I would be surprised if more than 5% of desktop GNU/Linux users are currently practicing an automatically scheduled backup regime, and maybe a tenth of those have off-site backup as well. Heaven help those in the way of the next lightning strike, flood, fire, or PC-pulled-off-desk-by-curious-infant.
very easy backup can be done with duplicity and rdiff-backup…
tar cvpzf backup.tgz –exclude=/proc –exclude=/lost+found — exclude=/backup.tgz –exclude=/mnt –exclude=/media –exclude=/sys /
Just in case you want to copy and paste the command rather than have to retype it …
You should be using pax and not tar. tar will not backup your filesystem metadata. pax superceded tar years ago. tar is fine for backing up bags of bits but not filesystems.
For example, you backup your Fedora or RHEL system as described above using tar and then restore it. Voila, your system is just as useless as if it had a blank hard disk because all of your selinux context data was ignored by tar.
Ahh thanks a lot for this! I’ve been meaning to do something like this for a while. I was just doing a dd to an external usb drive but this is better.
How about excluding /dev too ?!
I am using unified scripts for rsync and rdiff-backup from:
http://aulix.com/rsync-and-rdiff-backup
try this flag –one-file-system instead of all those –exclude flags!
tar cvpzf backup.tar.gz –exclude backup.tar.gz –one-file-system /
SELinux! Yikes.
Hi! I´m new to linux (learning and learning!) and I’ve just made de backup with the sugested tar method. But I can’t boot. I do can enter the boot menu if I want, the ubuntu logo appears and then, nothing happens. After some minuts, I get this error:
“BusyBox v1.1.3 (Debian 1:1.1.3-5-ubuntu12) Built-in shell (ash)
Enter ‘help’ for a list of built-in commands.
(initramfs)”
Please, please, help, help, help! There are days of configurations in that backup. I’ve tried the procedure more than once with the same results.
Thanks in advance!
Neat, I’ve never thought of using tar for backups. For file backup, I’ve used rsync as suggested above. For full disk/partition backups I’ve used DD pretty successfully.
If you need speed:
dd if=/dev/hda1 of=/mnt/my_server/recent_backup.dd
dd if=/mnt/my_server/recent_backup.dd of=/dev/hda1
If you need space:
dd if=/dev/hda1 | gzip > /mnt/my_server/recent_backup.dd.gz
gzip -dc /mnt/my_server/recent_backup.dd.gz | dd of=/dev/hda1