Clonezilla image copys to external hard drive for:
+Boot Partition
+Win7 Partition
+openSuse LVM partitions
+Regular Rsync backups to external drive for my home partition
The problem is that I do not know if this is enough to restore my system if all 3 hard drives fail, or if for example, only my non raid hard drive fails. So my first question is: Is this enough to restore my system? If not, what else do I have to look into?
If for example, my encrypted home hard drive fails, how would I go about restoring it and making my system functional again if I don’t keep a clonezilla image as I do for my other partitions, especially considering the fact that my home partition is encrypted and configured to open on the same password as my LVM partition.
IMHO, if you have backups of all your files on /home, you have the most important things (I conclude from your explanation that you do not have other file systems with user/application data like databases, web sites, etc.).
You can always restore from that backup, being it individual files (when one of your users cries: “Oh, i stupidly deleted the last love letter from my friend”), or being it to restore all of /home on a new file system after losing the old one.
The system itself is best recovered by re-installation (often quicker then trying to restore, even from a “clone” because clones may have UUIDs that do not fit anymore and that needs time for thinking and correction). It is however useful to also have a backup of all in /etc (in the same way as you rsync /home). Not for restoring, but for reference when you want to bring your re-installed system to the same configurations again (I call it “intelligent merging old and new configuration files”).
That is about how I manage it. Others may have very different ideas about this subject though.
But I didn’t understand your explanation about UUID. I didn’t know they took space, I thought they were just an identifier.
If I backup my /etc that contains my current fstab, wouldn’t I just need to modify the UUID of my new partitions to match the old ones on my fstab backup?
At any rate, I understand the Linux is quite simple and reasonably fast to restore through a clean install, but Windows is not (at least, as far as my capabilities go) so I’d rather try to stick to the cloning method unless there is some hassle that tops sitting through multiple updates and driver installs/reboots.
I probably should have posted this in my intro post, but these are the steps I think I need to go through to restore my system on new blank hard drives:
1-Boot from USB gParted Live
2-Plug in my MBR backup
3-Here I’m not sure what comes first… do I just restore the backup MBR (that include both partition table + bootloader) to these blank unformated disks, or do I have to format them before restoring the MBR? How can I be sure the that the newly formated partition table will be compatible with the one on my MBR backup?
4-Check UUID’s and modify if needed
5-Exit gParted Live, reboot
6-Run clonezilla
7-Restore system
8-rsync /home backup
Well all info takes up space. When you create a new partition a new UUID is assigned to that partition it is stored at the beginning of the partition. Since UUID is normally used to mount a partition changes to the UUID on a drive can cause boot problems. Cloning may or may not copy the old UUID depending on the exact program and methods used.
I am not hampered by much knowledge of Windows, thus your argument with some information about how things are done in Windows have no impact on my way to handle a Unix/Linux system restore.
I only mentioned the UUIDs because sometimes people start threads here because they are not able to handle “cloned” disks and/or partitions because they do not understand UUIDs and how to take care of them.
It is of course not difficult to handle them correctly, but you should know that they exist, where they are used, etc.
There is IMHO much misunderstanding about UUIDs and partitions. In fact partitions, which are simply “space”, have no UUIDs. And there is no place in an MBR partition table to store them *). What is on them, file systems or swap, can implement UUIDs. And of course they are stored into the file system (in the superblock if I am correct).
Thus the software that detects those “partition” UUIDs has to make some intelligent guesses about the contents of the partition (is there a file system, do I recognise the type as one I know where to look for the UUID …).
Take a look on the “helpful” articles on the Internet. Most will tell you that you can change your partition UUID with tune2fs. But that method assumes that there is an ext2/3/4 file system on the partition. It will most probably not work (or even destroy) other file systems.
*) GPT partition table has UUIDs for partitions. You can e.g. find them in /dev/disk/by-partuuid/.
I see, well I think I will scrap the cloning recovery method and only use it on windows as a way to roll back changes if something goes wrong there. But in case of a full catastrophe, I will just reinstall everything and restore data. I see now that I would need to study a lot more to get a safe full cloning method working.