Good Son, Back it up !

The most incredible hassle, that any computer user is likely to run in is DATA LOSS !! Well believe it or not, there are two kinds of persons :

1- those who regularly back up their data.
2- those who regularly loose their data.

I have never took it that serious about backups until a tragic incident, that ruined some good memorial days of my life !
Imagine you have spent almost 3 months coding, eating, drinking, wearing the same thing. And there it comes that sunny Saturday, where you have finally decided to lock your CVS repository and go out breath some fresh air, well enjoy some tits.
Wait a second! something is wrong !
This is not my last checking ! Where the hell is it ?
Well you can imagine how foolish a freak would act. In order to back up your ultimate achievement, you backed up the 1 months older one. And as usual that weekly cleanup script would screw things up even more, by removing older stuffs, uploading and so on ...(That's a bad habit !)
Debugging the file System would just have added more anguish and sadness.

Well that's true, the damage has been done ! But actually nothing's kept really from considering some preliminary cautions, in order to prevent such a disaster !

Here you gotta decide to which category you wanna really make part.
If you choose belonging to those miserable guys from the second one, then KISS YOUR DATA GOODBYE !

Save your Bacons !

Let's keep things as simple as possible and make it the pragmatic way.
Many individuals would automatically think of a proprietary costing product when it comes to backing. Claiming they do implement the most up to date technics and algorithms. Well that seems not being always the case, since some of them are built on top of poor archaic operating systems, and won't allow neither much portability nor new material support, and some others are simply greedy and will blow things to hell.
This is why I attempt to present the alternative methodology, in my regard the most reliable and most versatil: The old good Unix way!

Cautions:

• I will assume you'll be using a second media drive with enough mass storage to hold the backups. If you are planning to use an alternative with less space capacity, which will actually get slightly more awkward then prepare for more work.
  
• Never backup mounted root partitions directly ! boot from a second root partition: let's say a GNU/Linux or FreeBSD live CD, or simply a remote system (for instance netcat).
• None of the mentioned technics are edged in stone, there are a tremendous number of equivalent tools with at least the same functionnality. But for the sake of clarity and simplicity, let's make it easy.
• Each backup section will be accompagned by a well commented script that demonstrates the technics
  

Bare metal backup

This method emphasizes a bare metal backup using both dd and gzip. Loosely speaking, a sector per sector cloning. Hence everything is backed up including even the file system structure itself.
This method reveals to come in a handy way while dealing with total hard drives cloning. (Think of writing an automated restore procedure for your little sister, whom a malicious worm has just blown up her computer)

The syntax to backing up looks like:

dd if=/dev/hda conv=noerror,sync | pv | gzip -cf -9 > backup_date.gzip

restoring:

gunzip -c backup_date.gzip | pv | dd of=/dev/hda conv=noerror,sync

Explaining:
We read blocks from /dev/hda via dd command, then compress the output with gzip with full compression level (-9) in order to release some free space. When it comes to pv which actually stands for pipeline viewer, it just does make it possible to have an idea about the pipelined stream, hence build some predictions about remaining time.Finally the resulting stream is being transferred to dd, which in its turn will just write it back to hard drive.

Notes:
If you plan to back up only some specific partitions and not the whole hard drive, make sure to keep a safe copy of the MBR (master boot record) and the partition table in case the present ones get corrupted.
For the MBR which is actually only 512 bytes, you may want backup with :

dd if=/dev/hda of=mymbr.dat bs=512 count=1

and restore with:

dd if=mymbr.dat of=/dev/hda bs=512 count=1

For the partition table I recommand sfdisk which is to some extent safer than its ancestral fdisk. You backup with:

sfdisk -d /dev/hda > partable.sf

and restore with:

sfdisk /dev/hda <>

Explaining:

The first command makes sfdisk dump the hard drive partition table in a format that can be understood later on while resotring.

And finally there we are ! everything should have worked out right for us now.

NOTE !!
Always TEST TEST TEST TEST... whenever you find the right oppurtunity, test your backups and inspect every inch of it, untill you make sure it's gonna be by your side and rescue you once run into troubles