Howto: Backup and restore your system!

Quote:

---

Originally Posted by Patsoe

there would be another simple option though: dump.

---

"dump" is only useful if you can 100% guarantee that you will always backup + restore to / from the same hardware with the same disks and the same disk geometries ... E.g. "dump" is OK if you work with commercial UNIX-es and have e.g. your server room full of shiny new SUN server hardware and your storage room full of identical spare parts ...

But for a home user? Naaah, "dump" is too inflexible.

"tar" offers several clear advantages:

1. it does not care about the underlying filesystem ... whether it's ext3, reiserfs, XFS .. for "tar" this doesn't matter the least bit. You can without troubles restore the contents of a "ext3" filesystem to a new filesystem with "reiserfs" or SUN's ZFS or Windows NTFS ... It doesn't matter. It will work. With "dump": NOPE. Whatever filesystem you had when you did the "dump" will be the same filesystem you get when you do the "restore".

2. "tar" doesn't care about the underlying disk geometry. Whether you packed a 250 GB " / " filesystem and then unpack it onto a 50 GB drive ... "tar" doesn't care for as long as there is enough free space. But "dump" cares: If you change the disk geometries or play around with the partitions ... bye bye data, bye bye music collection. Unless I have missed any vast progresses "dump" is still the same stupid program it was 20 years ago and it just doesn't like it too much when you try to restore the dumped filesystem to a different geometry.

3. "tar.gz" files are de facto a universal standard. Anyone can read those files. Anytime. Anywhere. On any platform. Even on Windows, e.g. there are several tools such as WinZIP which are able to open "tar.gz" files and let you access your data. But "dump"? Nope. If for some stupid reasons you don't have the needed tools ready you won't be able to read those backups you made ... and a backup that can't be read is de facto worthless.

I am not saying that "dump" is just plain "bad" ... it has its uses and there are scenarios where I'd rather go for "dump" (see above). But fact is: for the average home user "tar" is the better bet.

Also ... something people seem to misunderstand: With "tar" you do file backups and that's what most people would want. With "dump" you do filesystem backups ... and that's not exactly the same thing.

Question... Is there a possible way at all to restore a ubuntu system without having to use the LiveCD??? I had to restore my ubuntu server last night, and it was a pain to take and move it from the shelf and connect it to a keyboard/monitor just to run the livecd. I'm wondering if there is a work around to do this remotely.
Thanks
Tim

Quote:

---

Originally Posted by scorp123

"dump" is only useful if you can 100% guarantee that you will always backup + restore to / from the same hardware with the same disks and the same disk geometries

---

I should say I haven't really looked into this in detail, but you can in fact restore individual files (see eg. here: http://surf.ap.seikei.ac.jp/~nakano/...WTO.en.html#s4 )

The other two points indeed speak strongly in favour of tar; it works on any file system and can be read in every OS. I think I'll reconsider my choice! Thanks.

Quote:

---

Originally Posted by Patsoe

but you can in fact restore individual files

---

Of course. But it's a pain in the a** ... You'd need to do a lot of things manually here, which takes time, and from that POV "tar" beats "dump" again, because even if you only wanted to restore a single file from a "tar" archive: oh well. You just specify what you want on the command line and "tar" will automagically do it for you, requiring very little if none at all interaction from you. And that's a big plus, especially if you have other things to do (who doesn't??) you can easily leave "tar" in the background and let it do its stuff. Not so with "dump" and its restore tool if I remember it right.

Best thing is this: Try it out. Install a PC and then make two backups:
- one with "tar"
- one with "dump"

And then destroy the data on the PC, e.g. format the disks so all data is lost. And then do a restore, a complete "bare metal" recovery. And then repeat the procedure. And then destroy a few important files and see how quickly you can get those files back ...

You will see which one works best for you.

nofear1101,

Your missing files problem is exactly why I like to boot with the Live CD before making a backup.

The last time I ran into your problem. I only had the /media folder (and its required contents) missing, so I manually recreated the missing files using konqueror:

Code:

---

$ kdesudo konqueror /

---

(By the way, don't use kdesudo with Dolphin).

I compared the "restored" system with a second working installation on another computer, created the missing files, and set the file permissions identically.

May be someone else can suggest an easier way to identify and recreate the missing files?

Hi guys, very nice tutorial ;)
What if I want to encrypt my backup?

Try using KGpg to encrypt/decrypt. You should store your back-up (whether or not it is encrypted) in a safe place-- perhaps burn it to a DVD or copy it to a separate physical drive. As per step 4 below, keep a copy of your Secret Encryption Key, which requires a password to function.

(1) Install Encryption Utility for Kubuntu...
$ sudo apt-get install kgpg
(Ubuntu users: $ sudo apt-get install seahorse)


(2) Start Encryption Utility...
"K" | "Utilities" | "KGpg"
(You may have to click on the "Lock" icon in the taskbar to maximize the GUI).


(3) Create an Encryption Key...
From the menubar, select "Keys" | "Generate Key Pair"
In the "Name" text box, enter a name for your key, for example "My Key".
Select "RSA" from the "Algorithm:" dropdown.
Click "OK".
Click "Continue"
Enter, and verify, your secret password in the "Password" fields.
Click "OK".
(You may chose to set this key as your default key).
Click "OK".


(4) Export (Backup) your Secret Key...
In the "Key Management" window, right-click on your Key.
Select "Export Secret Key..."
(Make sure you select "Export Secret Key...", not "Export Public Key...")
Click "Export".

(Note, be sure to keep your exported Secret key file in a safe place, so you can import it into KGpg in case you have to restore your system from an encrypted backup. If you lose this key file, you will not be able to decrypt an encrypted file even though you know the password!!! To import the key file, simply drag it into the "Key Management" window, click "Import, and click "OK".)


(5) Encrypt Your File...
Navigate to your file in Dolphin.
Right-click on your file.
Select "Actions" | "Encrypt File"
In the dialog that appears, select the key you created in step 3 (ex. "My Key") and click "OK"
An encrypted file will be created with an *.asc extension.
Note: a large file (such as a backup) may take some time to encrypt.
Delete your original *un*encrypted file.


(6) Decrypt Your File...
If necessary, import the key file into KGpg by dragging it into the "Key Management" window. Click "Import, and then click "OK".
Navigate to your encrypted file (with the *.asc extension) in Dolphin.
Click on the encrypted file.
In the dialog that appears, enter your password.
Note: a large file (such as a backup) may take some time to decrypt.

http://www.truecrypt.org/ :)

My simple implementation of Apple Time Machine like backup. Hopefully it will be useful for somebody.
Disclaimer: rsync is pretty new thing for me.

These are the contents of my archive.sh:

Quote:

---

#!/bin/sh
BACKUP_ROOT="/media/sdc1/backup/rsync/"
THIS_BACKUP="$BACKUP_ROOT`date|sed \"y/ /_/\"`"
cd $BACKUP_ROOT
PREV_BACKUP="$BACKUP_ROOT`ls -rt|tail -1|sed \"y/ /_/\"`"
rsync -axy --link-dest="$PREV_BACKUP" /home/xebec "$THIS_BACKUP"

---

BACKUP_ROOT is the folder where all backups are stored. Make sure it does not contain spaces and is located on linux partition. Make sure /home/xebec is replaced with the list of folders and files you want to back up.

Basically, rsync will create fully identical copy of your folders every time you start the script. However, If you mount some other drive into your home folder, rsync will ignore it, since -x option is specified.

The reason I use rsync instead of plain old `cp -a` is that it can compare your folders specified for backup with previous backup. And this is the coolest part: in case the identical file is already there, rsync will not copy it over again. Instead it will create a hard-link, preserving your hard disk space and time. I have about 13 gigs to backup, but each new backup takes only about 50 megs of space on average. That's why I don't even bother deleting my old stuff.

In case you want to delete some old folders, the hard-links in your newer folders are going to be safe, since your file system will delete only the contents of the files which do not have any hard links left.

You probably want to schedule automatic backups. So you open

Quote:

---

sudo gedit /var/spool/cron/crontabs/root

---

Here is my entry to the crontabs for automatic backups every day at 4 am:

Quote:

---

0 4 * * * /home/xebec/my_scripts/archive.sh >>/root/backup.log 2>&1

---

/root/backup.log can be replaced with /dev/null if you don't need backup logs.

If you only want to backup certain directories and then use ncftp to get the tar file off the machine to a local ftp site...this works great! You'll need to have ncftp installed, and tweak the 'ftpserver', 'ftp*' spots, etc. Paste this into a file, save it as 'backup.sh', set it to run nightly as a cron job and you're done.

Notes: This backs up any dirs listed in DIRS - just list as many as you want seperated by a <space>. Most of what needs tweaked are in the first two sections (System Setup and FTP Server Setup).
-------------------- shell script follows ----------------
#!/bin/sh
# System backup script
# Full backup day - Wed (rest of the week do incremental backup)
# ---------------------------------------------------------------------

### System Setup ###
DIRS="/var/www/html /etc/nagios /root"
BACKUP=/tmp/backup.$$
NOW=$(date +"%d-%m-%Y")
INCFILE="/root/tar-inc-backup.dat"
DAY=$(date +"%a")
FULLBACKUP="Wed"

### FTP server Setup ###
FTPD="ftpdirectory/incremental/"
FTPU="ftpusername"
FTPP="ftppassword"
FTPS="ftpsharename"
NCFTP="$(which ncftpput)"

### Other stuff ###
EMAILID="you@hotmail.com"

### Start Backup for file system ###
[ ! -d $BACKUP ] && mkdir -p $BACKUP || :

### See if we want to make a full backup ###
if [ "$DAY" == "$FULLBACKUP" ]; then
FTPD="/ftpserver/full"
FILE="fs-full-$NOW.tar.gz"
tar -zcvf $BACKUP/$FILE $DIRS
else
i=$(date +"%Hh%Mm%Ss")
FILE="fs-i-$NOW-$i.tar.gz"
tar -g $INCFILE -zcvf $BACKUP/$FILE $DIRS
fi

### Dump backup using FTP ###
#Start FTP backup using ncftp
/usr/local/bin/ncftp -u"$FTPU" -p"$FTPP" $FTPS<<EOF
mkdir $FTPD
mkdir $FTPD/$NOW
cd $FTPD/$NOW
lcd $BACKUP
mput *
quit
EOF

### Find out if ftp backup failed or not ###
if [ "$?" == "0" ]; then
rm -f $BACKUP/*
else
T=/tmp/backup.fail
echo "Date: $(date)">$T
echo "Hostname: $(hostname)" >>$T
echo "Backup failed" >>$T
mail -s "BACKUP FAILED" "$EMAILID" <$T
rm -f $T
fi
-------------- end shell script ----------------

Alternatively, here's where I generated that script, a cool script generator, it just prompts you for some info and spits out a script:

http://bash.cyberciti.biz/backup/wizard-ftp-script.php

Enjoy! :guitar: