Hi all,

I've finally got round to installing a linux OS on my laptop and have been having fun tinkering and learning but this morning I made, what I'm sure won't be the last, major mistake.

As root I rather than which quite rightly knackered my OS and I ended up re-installing everything.

Is there any way to fully backup my OS so that should I get myself into this sort of situation again I would be able to restore my way out of it? I've got a second 1tb HDD in the laptop that I'll use to store the backups.

I've seen tools like clonezilla that can take a full backup of a disk but I'm hoping for something I can run incrementally so it's not a fully disk backup every time.

Thanks in advance!
Jack

I've heard good things about Back in Time, which is a GUI frontend for rsync. I've not used myself.

I use rsync itself from time to time to back up my laptop's /home directory to external media; I say "from time to time" because significant changes warranting backup don't happen all that often on my laptop. When it comes to system configuration files (those found in /etc, as opposed those in /home), I back up only those which I have changed or expect to change, such as /etc/samba/smb.conf.

If I have truly significant data to back up, I usually back it up to at least two external hard drives.

On of the nice things about Linux is that a restore or reinstall is a last resort. If you make a mistake, can often fix it short of that. For example, if you muck up a config file, you can boot to a live CD of something or other, mount the hard drive, and often fix the problem by re-editing the file. I learned that you could do that by mucking up a config file.

I use rsnapshot, which uses rsync to do incremental backups, to make daily, weekly, and monthly backups of an entire server configuration to another, off-site, server. It can also be used to make in-place copies -- I'm reluctant to call them backups if they're on the same HDD -- if that might me useful.
I don't think it has a GUI, tho.
:: Oh, you said second HDD. Yes that will work well with rsnapshot.

As others have suggested, rsync is an excellent utility. Personally, I use it on the command line as I don't like gui utilities much. I'd check out the Arch wiki https://wiki.archlinux.org/index.php...backup_utility for more information

You can can make an exact, bootable back-up with dd:If you want to restore, simply do:and the system will be fully functional as it was when you made the back-up, including the boot sector and partition table; two things rsync doesn't back up.

While that is true, OP specifically asked for

Which illustrates one needs to really understand why a backup is needed. What you ask for may not be what you actually want.

I use several different tools (on the one system) depending on requirement. But I never use dd (for backups) - I prefer to have some confidence that the filesystem(s) is readable. But I have no problem having to re-install grub in a disaster - that's likely to be the least of my concerns in such a situation.
So:
- fsarchiver (compressed, CRC, point-in-time complete filesystem backup)
- rsnapshot
- rsync

How many of you people test your backups before you actually need them ?.

I use Debian and I do full OS backup synchronization all the time. If you want a true bootable backup that includes the exact same MBR and such, you've got a little problem: by default Debian uses UUIDs and having two partitions in the same physical box with the same UUIDs can be a problem.

My experience is that it's okay to temporarily have cloned UUIDs for when I am cloning hard drives or partitions. But when you boot with identical UUIDs around things can get messy. The solution is this:

A) Don't have the same UUIDs!

B) Modify your /etc/fstab to use device names instead of UUIDs. Be aware that this means you have to be careful which SATA cable is attached to which hard drive, so the correct hard drive is /dev/sda. OTOH, this makes swapping in the backup easy. You just power down and swap SATA cables!

So, a way to do all this is:

1) Do a clean Debian install on the first drive. Do manual partitioning. Wipe out all partitions on /dev/sda and /dev/sdb and create exactly ONE partition on /dev/sda for the OS and ONE partition on /dev/sdb for the backup. DO NOT CREATE A SWAP PARTITION (this will make everything more complicated later on if you do; if you really need swap create a swap file later). Make these partitions the same size; something like:

Note that because you created sdb1 using the Debian installer, it will have a different UUID than sda1. If you had used the "dd" method to clone sda, it would create cloned partitions with cloned UUIDs. Not good for this use case!

When the Debian installer asks where to install GRUB, do it in /dev/sda.

2) Boot up to your Debian install

3) Use the following command as root to create and later sync up the backup of sda1 to sdb1:

The first time will take a while. From then on, it will typically take a few seconds or less just to incrementally update the changed files. The flags used are:

-v = verbal output (so you can see all it's doing)
-a = archive mode
-x = only one file system (in this case, only /dev/sda1)
-AX = preserve ACLs, file attributes
--delete = delete files that don't exist in the source

4) Modify a temporary /mnt/sdb1/etc/fstab so we can install grub on sdb. You'll want to swap mount points of "/" and "/mnt/sdb1".

Modify to something like this:
5) Create an auto-detected boot menu entry for sdb with:
6) Reboot into sdb. There will be two Debian options. Choose the second. You can confirm which partition you've booted to with the "df" command.

7) Update grub and install MBR bootloader on sdb with:

grub-install /dev/sdb[/code]

This will install the grub2 bootloader on sdb, pointing to the UUID of /dev/sdb1. Note that the configuration in /boot and /etc/fstab will later get overwritten by your backup rsync. This was just done to get the grub2 bootloader properly installed on /dev/sdb.

8) Reboot to sda (the first boot option).

9) Modify /etc/fstab to replace UUIDs with device names. It will start something like this:

Modify to something like this:
10) From now on, use the rsync command to backup from sda1 to sdb1. To repeat the above command:
If you ever need to use your backup, power down the computer and swap SATA cables.

1 members found this post helpful.

Ugh...sorry, read too fast. Missed out on "laptop".

A much simpler solution in this case would be to just rsync to an backup like this:

Change "/mnt/bigdrive/osbackup" to whatever path is to your backup folder (create such a folder somewhere on the 1TB drive).

Later on, if you need to restore, boot to a liveCD or a second Debian install if necessary and use rsync to copy back to the main OS drive:
Replace /mnt/sda1/ with whatever path /dev/sda1 is mounted on.

Additionally, you can use "dd" to backup and restore the MBR/partition table (assuming we're talking an MBR drive):

backup MBR
restore MBR

@TheEzekielProject

Point taken. I guess my speed-reading class didn't really pay off.

Just a couple of notes:
This is quite a limitation, IMHO. Separate partitions can be immensely useful.

Note that a swap file is not capable of suspend to disk support, a swap partition is required.

Not to go off topic, but, Evelyn Woods?

It also makes it a lot more complicated to maintain a drop-in backup. Which is fine if you think it's worth it. I was just giving a bare simple example which would work. Unfortunately, I was describing a solution suitable for a desktop computer (with internal SATA cables that you can just swap). For a laptop, especially one with two different drives that can't be swapped, it's a different situation.

Yeah, a swap partition is required for suspend-to-disk (hibernation). It is not required for normal suspend, though, which I think is an important distinction to make because many people find suspend useful but hibernation not useful.

Hibernation is just so incredibly slow and sluggish in both directions compared to normal suspend. Considering normal suspend can conserve a low battery for a long time, well...

Okay, I see a use case for hibernation. If you're the sort of person who doesn't save regularly and you also have a tendency to leave your laptop unattended, and you often work off of battery, and you might leave the laptop unattended for more than a few days (however long it will last in normal suspend mode), then having the OS emergency hibernate on low battery can save you from losing your unsaved work. And really, it only takes one "save" to make it all have been worth it.

Personally, I'm used to using desktop computers at work; most of them have no UPS. The occasional power outage keeps me in the habit of saving often. As such, I just don't fit the use cases where hibernation is useful.

Wow, thank you all for the massively detailed responses! It looks like rsync to dedicated partition on my second HDD should do what I want!

So RSYNC is going to basically synchronise my OS to the second HDD and should I get into a position where I've messed everything up I can boot into a live cd and just RSYNC everything back to restore my OS to the original position?

I'm happy modifying FSTAB to get everything mounted how it should be.

I'm sorry for confusing things about fstab changes. You don't need to do that for your case. I was mistakenly thinking in terms of a desktop computer, setting things up so that the backup could be a drop-in replacement.

If you just want to be able to save and restore, and you assume the primary drive itself doesn't go bad, it's much simpler. You don't even need to set up a separate partition for the backup. Just create a folder on any partition with sufficient space.

I'll assume the backup folder is /mnt/sdb1/debback/

You simply save/update with:

You can restore by booting up to a liveCD or a second OS install with something like:

The actual paths will be a bit different from that, depending on how the liveCD is set up.

Additionally, you can save/restore the MBR/partition table with:

backup MBR
restore MBR
In this case, first "cd" to the folder where you want to store boot.img

1 members found this post helpful.