Backup solutions for Linux

That AptOnCD seems to be rather slick, something I'll take a look at. As for Clonezilla, I'm now on beta 1.2.3.27 and no issues at all, as with the previous beta.

 

Hi wat0114,
As an experienced Clonezilla user, I need your input: have you got any idea why after restoring both the SSD and partition (I have only one on my system) I should be getting just a GRUB prompt (grub >) and failure to boot any farther?

I started out restoring the full disk, then dropped back to the partition, hoping for a difference, but there was none.

I am a Clonezilla newbie, just using it for a few days by now.

System Info:
Hardware, ASUS L7014G
OS: Leeenux Ubuntu v2
Clonezilla: most recent stable version

 

I'm not sure why that's happening to you, and I've never used a SSD before, but I don't know why that might cause problems. Where is the directory located that you're mounting to restore/backup the images from?

BTW, Mrkvonic provides an excellent tutorial on Clonezilla here just in case you want to verify you're going through the steps properly.

 

To answer your question, where is the directory:
It's in an external FAT32 USB drive and I'm letting Clonezilla go to its root directory.

I'll check the tutorial, but wanted to get back to give a reply, as your fast response is much appreciated. I've been banging my head against the wall for a couple of days on this one, since everyone says Clonezilla works so well,for them!

New information:
A Google search on
"clonezilla" "failed to install grub"
is getting lots of hits, but so far, the only suggestion is to reinstall grub from the command line. Nothing on why it occurs or how to prevent it.

Details on Clonezilla's error message:
file /tmp/hd-img.2#aJj5/boot/grub/stage1 not read correctly.
also:
Failed to install grub !!
Yes, in red and with the exclamation points.

I'm really a linux newbie so details are appreciated.

 

How do you have your drive partitioned? You mention only one, so is it not similar to the way I have mine in three partitions (within an extended partition) as root (/) swap & /home?. I have grub 2 installed in the root partition. When I use Clonezilla to backup/restore, I backup/restore the root and /home partitions separately. I've never had an issue with grub not restoring.

 

Sorry, I wasn't counting Swap. It's Root and Swap.

This is the default installation from the Ubuntu variation I mentioned, but I think it's the way Ubuntu installs normally?

I have heard a Home partition is a great idea, but I want to make sure I can image and restore, before I begin customizing. So in effect, I was imaging an OS that had been installed minutes earlier, with nothing done to it.

Just tried to restore again, with the BIOS set for Install (as opposed to finish) but got exactly the same error.

 

I don't understand what's going wrong with the backup/restore process, then?? You must be using Clonezilla v 1.2.3.27? Canyou boot off the live cd and use Gparted to scan the drive? Does it show the Root partition with the "Boot" flag?

 

You raised a very good point, as I just found that through extensive 'Googling' someone who had this problem said the same, and that it solved the problem.

I suppose once it's set, it should stay set? This is pretty new to me.

I take a look at this ... learning as I go! Probably have to continue in the morning, as it's getting late here!

 

Yes, it's set as boot.
And there are three partitions, the Ext4 (/dev/sda1), an extended and swap partitions.

I see that grub can be in two places: the 'normal' place (would that be outside of the partition??) or in a Superblock inside the partition. Could grub be somewhere, on my system, where Clonezilla doesn't expect it? If that make any sense (not really, to me) then does this point to anything in your experience?

 

The only other idea I have is that maybe with your USB stick inserted, Clonezilla is seeing it as, maybe, hd0 and your root part as hd1, whereas your grub menu is assigning hd0 to the root, as it should, so somehow, perhaps, Clonezilla is messing up the grub before the imaging process by assigning the wrong hdx (where x is 0 or 1)? You can check your grub entries by opening menu.lst which might be under: /boot/grubmenu.lst. You can see in my ss where it's pointing at (hd0,4) which just means harddrive 0, partition 4. Just grasping at straws because I'm otherwise out of ideas. There are many others in this forum who have far more expertise in this area, so hopefully someone will post some ideas.

 

Thanks much for your efforts -- I will try this and if problems persist, go to another imaging solution compatible with Ext4.

I note Clonezilla is aware of this problem, but doesn't know what's causing it, either. The only work-around on their web site is a (very complicated) method of recovering the system by reinstalling GRUB.

 

Hi Ron,

there is something wrong it seems with the Clonezilla disk cloning function. It restored the Windows part just fine, failed on the Linux parts, successful on my Backups part, failed on my Storage part. The "Restore Parts" function has been quite reliable for me, except last week when it failed to clone to an equal size part on my other h/drive. I'd say Clonezilla is kind of buggy In fairness, though, I'm using the latest test version (1.2.3-27).

 

[Resolved] Backup solutions for Linux

Clonezilla has lots of happy users, but I agree with your comment. When the disk image-restore damaged grub, I also tried the partition image-restore function, but it did the same: boot failed, again, at the grub prompt. As I said, time to move on ...

So, I downloaded the .iso for something called SystemRescueCD, a 'live' disk that permits running fsarchiver (Ext4 compatible imager), from its own GNU/Linux Command Line. I reinstalled the OS, imaged, then restored my L701 SSD with fsarchiver, powered it up and booted -- grub worked fine, and then Leeenux started perfectly, and continues to do so, more than 24 hours later.

Thanks for confirming what I was suspecting ... it's nice to know I'm not the only one!

[edit: the beta version of SystemRescueCD is recommended, for the latest fsarchiver. Also, the name is fsarchiver -- I think fsarchive may be something else. ]

 

I'm not sure if Clonezilla is buggy, but you can certainly run into problems when cloning to different hardware. That's what I was faced with just 2 days ago.

I cloned my system from an old IDE disk to a new SATA disk (and enabled AHCI in the BIOS in order to benefit from NCQ). I booted from the new disk, the Grub menu appeared - but then I got error messages like "device /dev/disk/by-id/ata-Maxtor_6Y120P0_Y34449ME-part6 not found". This was a reference to my old harddisk.

Therefore I booted again from the old disk and mounted the new one. To fix the problems I had to do 2 things:

1. I went to /dev/disk/by-id in order to find the disk-ID for the new harddisk. Then I simply replaced the ID of the old disk with the ID of the new disk in the corresponding lines in /etc/fstab and /boot/grub/menu.lst on the new harddisk. Example: In fstab
   
   Code:

   /dev/disk/by-id/ata-Maxtor_6Y120P0_Y34449ME-part6

   became
   
   Code:

   /dev/disk/by-id/ata-SAMSUNG_HD252KJ_S0NJJDWQ108187-part6

2. Then I checked which drivers for the disk controller were used by executing
   hwinfo --storage-ctrl
   I got several info blocks. One of them looked like this:
   
   Code:

   28: PCI 1f.2: 0106 SATA controller (AHCI 1.0)
     [Created at pci.318]                       
     UDI: /org/freedesktop/Hal/devices/pci_8086_2923
     Unique ID: w7Y8.9YfA3CDazC2                    
     SysFS ID: /devices/pci0000:00/0000:00:1f.2     
     SysFS BusID: 0000:00:1f.2                      
     Hardware Class: storage                        
     Model: "Intel 82801IB (ICH9) 4 port SATA AHCI Controller"
     Vendor: pci 0x8086 "Intel Corporation"                   
     Device: pci 0x2923 "82801IB (ICH9) 4 port SATA AHCI Controller"
     SubVendor: pci 0x1458 "Giga-byte Technology"                   
     SubDevice: pci 0xb005                                          
     Revision: 0x02                                                 
     Driver: "ahci"                                                                                                                                                                                          
     [B]Driver Modules: "ahci"[/B]                                                                                                                                                                                  
     I/O Ports: 0xe600-0xe607 (rw)                                                                                                                                                                           
     I/O Ports: 0xe700-0xe703 (rw)                                                                                                                                                                           
     I/O Ports: 0xe800-0xe807 (rw)                                                                                                                                                                           
     I/O Ports: 0xe900-0xe903 (rw)                                                                                                                                                                           
     I/O Ports: 0xea00-0xea1f (rw)                                                                                                                                                                           
     Memory Range: 0xfa006000-0xfa0067ff (rw,non-prefetchable)                                                                                                                                               
     IRQ: 28 (58575 events)                                                                                                                                                                                  
     Module Alias: "pci:v00008086d00002923sv00001458sd0000B005bc01sc06i01"                                                                                                                                   
     Config Status: cfg=new, avail=yes, need=no, active=unknown 

   Then I looked into /etc/sysconfig/kernel. Therein I found the following line:
   
   Code:

   INITRD_MODULES="thermal pata_jmicron ata_generic ide_pci_generic processor fan"

   Ah - ahci was missing! So I added that to the above list of modules.

Now I booted from the new disk and all was well

Thus, if you know what to do you can get around this trouble although it's not trivial at all for a normal user. The problem is that you don't find any hints on http://clonezilla.org/ (at least I didn't find any) although you should run into these problems whenever you clone your system to a different drive (regardless if your distro uses disk-IDs or UUIDs - in the latter case you should execute blkid to find them out).

I'm not aware of an easier method. Can SystemRescueCD fix such problems?

 

In general, when cloning an image (whether CloneZilla or just tar/cpio) to other machines (hardware), rebuilding initrd is always a good idea. And using by-name notation, as then there are no confusions. If devices contain partitions that are formatted, then using the same inode size.
Mrk

 

Yikes, that looks like a lot, although I could probably handle it, I suppose. Maybe it is a disk id problem but I don't know why it should be in my case using the same machine hardware and physically identical drives. This has never been an issue for me using Acronis or ShadowProtect. However, both h/drives are exactly the make/model, and I'm cloning within the same machine, so there are no hardware changes between clones.

So that's just it, as I mentioned above, it's all within the same machine/hardware, and even the drives are both WD Caviar Black, 500 GB drives. Unless, as what happened to tlu, the drives are different id's and Clonezilla doesn't like that?? IMO, Clozezilla should have been able to handle the cloning process. Funny that it handled the Windows 7 system partition flawlessly and one of the ntfs storage partitions, but not the Linux parts or the other ntfs storage partition

 

Yes - but is that really easier than the method I described above? I mean if you apply mkinitrd you have to chroot the system (which is a problem for most users), and if you don't know which options to use for mkinitrd, you have to make the changes in fstab, menu.lst and /etc/sysconfig/kernel anyway.

I may be wrong but I think for the average user the steps described in my posting above might be more familiar than experimenting with chroot and mkinitrd.

 

For cloning Windows or for cloning Linux?

Yes, but I think the IDs should be different anyway. You can check it by attaching both disks, mounting the second one and going to /dev/disk/by-id and /dev/disk/by-uuid.

 

Cloning Windows. So does the disk id play a role in Linux cloning?

You are right, I remember seeing different id's assigned to them when using the Clonezilla disk.

 

Yes, since the entries in fstab and menu.lst are no longer correct.

Thanks for confirming this. Everything else wouldn't have made sense

 

Thanks for your help, tlu! It's too bad disk id's make all the difference using Clonezilla with Linux, so I will try what you did and see if that works.

 

You're welcome.

Not only Clonezilla but any other alternative has the same problem. I am not aware of a backup/cloning program that automatically adjusts disk-IDs (and driver modules) to new hardware. Perhaps somebody else ...?

 

RonCam,
I've had that problem as well not too long ago. What distro are you using? What version of CloneZilla are you using? If Ubuntu, what version? The problem I had related to the version of CloneZilla I cloned with and was using. Grub was the culprit. I switched to a different version of Clonezilla and was able to restore with no problem. Your image is probably fine.

I've been using CloneZilla a long, long time and I've never had a problem that wasn't of my own doing. I hope CloneZilla soon includes btrfs as an option. I remember they were quick to adopted ext4.

 

I'd say you're right about grub 2 as the culprit. There really is nothing wrong with the image. I used the grub 2 repair procedure as explained here and the problem is solved. Also, I had to first use the second option in clonezilla to use disk-disk, then choose clone local partition to local partition to restore the root part to my target drive (this avoids the Clonezilla error: "failed to restore partition...maybe image is corrupt" message), after which I just got the "GRUB" prompt as RonCam got, then after I ran the Grub 2 repair procedure, all is good again

This has ended up being a nice learning experience, a good thread, even if frustrating at times. The important thing is I've learned something new Linux-related. Thank you to all who've responded and offered suggestions RonCam, good to see you battled through some adversity and you arrived at a resolution

 

You're right, too much for an average user.
I'll think of something that might make (easy) sense for cross-platform cloning.
Mrk