Why does FSarchiver not restore
 

Based upon both my experience and some initial research, I concluded that FSarchiver does not restore grub to your destination drive.

#1
Why is that? It seems really silly to ignore the booting ability.

#2
Is there any way I can get it to restore grub when it restores the image? In other words, I don't want to take a 2nd action just to restore grub. However, if I did have to take a 2nd action to restore grub, then what would be the easiest method?

Bad conclusion. Or poorly worded.
fsarchiver restores the filesystem you backup up.

What else would you expect ?.

I disagree that the OP drew a bad conclusion. It is entirely legitimate to expect FSarchiver to restore the boot loader. Not that it is an absolute requirement that it does so, but partimage, for instance, does. My reason for using FSarchiver instead is the lack of support for ext4 in partimage.

When I restore a bootable partition with FSarchiver, I subsequently boot from a CD for the distro that I have just restored, mount the required directories with the "--bind" option (depends on which distribution you're working with), do a "chroot" into the restored partition, and run the commands to reinstate the boot loader.

I'm willing to provide more details if you wish, but I cannot do so right now. Let me know if you want them (possibly telling me what's your distro), and I'll give you an example.

luvr - thanks for your reply and yes, I welcome any examples.

I currently use Kubuntu 14.04 64 bit. I am using it on a bootable 16 gb USB flash device. Everything is on 1 partition (root) for simplicity.

So, does this mean FSarchiver does not save boot? I don't understand why one would save only a "filesystem". Without boot, isn't a filesystem unaccessible, therefore useless?

The thing with FSarchiver is, it makes a file-by-file backup, as opposed to partimage, which makes a block-by-block backup.

Thus, partimage will restore the used disk blocks to there original locations on the disk, including the blocks required by the boot loader.

FSarchiver, on the other hand, will restore each file in turn, and completely rebuild the filesystem from scratch. It will not take into account the original locations of the files on the disk, and it will ignore any blocks that are not part of any file—specifically, the “Root Block” (a.k.a. “Superblock”) of the partition, which contains the very first piece of boot loader code to get the system boot process going.

Note:

The above description does not apply if the boot loader for your Operating System sits on the Master Boot Record of your hard disk—in which case the Superblock of the partition will play no role in the boot process.

Also, if your Operating System boots from the Superblock, then the first steps in the boot process cannot locate any files on the partition. The first few files that must be loaded, will, therefore, have to be addressed by Block Address, instead of by file name. However, it is highly unlikely that, when you do a file-by-file restore, these files will end up at the exact same block addresses that they originally held. In other words, there’s no point in keeping a backup of the Superblock and restoring it, because the Superblock will include the block addresses of the files that it must load, and after the restore, the files will almost certainly have moved to different locations.

It could well be that, if your boot loader is GRUB, and if it sits on the Master Boot Record, then your Operating System will be bootable without any further actions on your part after you restore it with FSarchiver—though I haven’t actually tested this.

By the way, without boot, the filesystem isn’t really inaccessible; you can still mount it and use its contents. You just cannot boot it any longer.

Having said that, on to the important part:
Great—Ubuntu 14.04 is one of the distros for which I have actually worked out the exact steps. In what follows, I will be talking about “Ubuntu” as a generic term; whether you use Ubuntu, Kubuntu, or any of the other editions doesn’t matter—for this discussion they are fully interchangeable. Just make sure that you’re using the correct Ubuntu version (e.g., 14.04) and the correct architecture (e.g., 64 bit).

To reinstate the boot loader for your Ubuntu system, follow these steps:

• Boot Ubuntu from some other medium than your restored system partition—e.g., from another Ubuntu system partition on your hard disk, or from an Ubuntu Live CD, etc.

• Identify the Ubuntu system partition onto which you need to reinstall the GRUB Boot Loader. I will represent this partition as “/dev/sdXY”.

• Open a command-line terminal window.

• Since the following commands require ‘root’ privileges, you may want to ‘become root’ once and for all, and be done with it. Type the following command:
  
  Code:

  ---

  sudo -i

  ---

  Your prompt will change to the root prompt.

• Mount the Ubuntu system partition that you identified above:
  
  Code:

  ---

  mount /dev/sdXY /mnt

  ---

  Note that, instead of using ”/mnt”, you could create another directory and use that as your mount point. You would, then, obviously, have to modify the following commands accordingly.

• “Bind-Mount” the required system directories to locations under the newly mounted partition. Under Ubuntu, the following bind mounts will be needed (other distros may require a different set of “bind mounts”):
  
  Code:

  ---

  mount --bind /dev    /mnt/dev
mount --bind /dev/pts /mnt/dev/pts
mount --bind /proc    /mnt/proc
mount --bind /sys    /mnt/sys

  ---

  The contents of these essential system directories are now accessible from two locations: their original locations (e.g., “/dev”), as well as the locations to which the above commands bind them (e.g., “/mnt/dev”).

• Start a chroot jail, with the mounted partition as the apparent root directory:
  
  Code:

  ---

  chroot /mnt

  ---

  The following commands will be run as though your computer was booted from the mounted system partition (except for the system directories that were “bind-mounted”, which will be obtained from the originally booted root directory).

• From the chroot jail, reinstall, recheck, and update the GRUB boot loader:
  
  Code:

  ---

  grub-install --force /dev/sdXY
grub-install --recheck --force /dev/sdXY
update-grub

  ---

  (In principle, only one of the “grub-install” commands should be required, but I have had mixed results when omitting either one.)

• Exit the chroot jail:
  
  Code:

  ---

  exit

  ---

• If you want to properly clean up, then unbind the system directories from their locations under the mounted partition:
  
  Code:

  ---

  umount /mnt/sys
umount /mnt/proc
umount /mnt/dev/pts
umount /mnt/dev

  ---

  Then, unmount the partition:
  
  Code:

  ---

  umount /mnt

  ---

You should now be able to boot your restored Ubuntu system partition again.

luvr - wow, thank you for the extensive information. I will look at the example too.

I noticed your Ubuntu "how-to" uses lots of command line. Is there a GUI alternative? Like most Windows users, command line frightens me!

You stated FSarchiver makes a "file-by-file" backup instead of a "block-by-block" backup. Is that why FSarchiver can restore to a destination of any size, so long as the destination is big enough to hold the uncompressed files?

Follow-up for luvr:

You wrote "It could well be that, if your boot loader is GRUB, and if it sits on the Master Boot Record, then your Operating System will be bootable without any further actions on your part after you restore it with FSarchiver—though I haven’t actually tested this."

I want to test this. How would I do so? What steps must I perform?

Thank you again.

If there is a GUI alternative, then I’m afraid I’m not aware of it. I understand your reluctance to start typing commands when you come from a Windows background—I used Windows long enough to get a feel for the culture shock when you suddenly find yourself confronted with a command-line console. Once you get the hang of it, however, I’m sure you will learn to appreciate its power and flexibility.

Exactly! FSarchiver does record the size and file system of the partition from which you made the backup, but since it will completely rebuild the file system when it does a restore, the destination need not be the same size, or even the same file system, as the source.

For starters, you will have to make sure that it’s safe to do so.

For the sake of this discussion, I will assume that you are using a Windows computer, and that, whenever you boot the computer from the hard disk, Windows will automatically start.

If that is the case, then your Master Boot Record contains the default Windows Boot Loader.

If you want to install GRUB onto your Master Boot Record, then you will overwrite the Windows Boot Loader, and replace it with GRUB. From then on, whenever you boot your computer, a boot menu will appear, from which you can choose to start Windows or whichever Linux system(s) you have installed on your computer.

One caveat: GRUB needs to load a number of files from its “boot” file system—which must be present on your hard disk, and should remain in place for as long as you want to keep using GRUB as your “Master Boot Loader”.

The most common way to get the “boot” file system installed on your hard disk, is by installing Linux onto your hard disk. If you install the entire Linux system into a single partition, then the “boot” file system will be that partition (you will find the “boot” file system contents in the “/boot” directory within the partition). In this case, the GRUB boot sequence works something like the following:

• The initial Boot Loader code is loaded from the “Master Boot Record” of your hard disk.
• Given that this “Master Boot Record” is just one disk sector (i.e., 512 bytes), it is clear that it cannot contain much code. It certainly cannot contain enough code to make sense of any file system on your computer; in other words, it cannot locate any files on the “boot” partition.
  Therefore, in order to be able to access the “boot” files by file name (instead of by disk block address), the initial Boot Loader code will need to load some additional code from somewhere, and it will have to use disk block addresses to locate it.
  Now, GRUB uses a pretty dirty trick to locate the additional code that it needs in order to obtain access to its “boot” partition: When you install GRUB to the Master Boot Record, it will dump this additional code to the “empty” space between the Master Boot Record (which sits on the very first sector of the disk) and the first partition. Subsequently, whenever you boot the computer from the hard disk, the initial GRUB Boot Loader will read the code from there, and execute it.
  In fact, the act of dumping this extra code to this empty space, is what GRUB calls ”embedding”—which is only made possible because the empty space happens to be there. If you install GRUB onto the “Superblock” of a partition (instead of on the “Master Boot Record”), then there will be no such empty space available, and this ”embedding” will not be possible; as a result, GRUB will, then, have to resort to using disk block addresses to locate its boot files—which is somewhat brittle, as it relies on the files remaining at their fixed positions.
• The additional code that is now running, includes enough code to make sense of the “boot” file system. It will, therefore, be able to read the files that it needs from there, and subsequently complete the boot process.

From the above description, one critical observation should be made:
Therefore, if you install GRUB onto your Master Boot Record, and you decide later on that you want to remove Linux from your hard disk, you will have to reinstall some other boot loader before you zap the “boot” file system. For instance, I guess that Windows should provide some means to repair its default boot loader (though I have no idea how); thus, before you ever remove Linux (or, specifically, the GRUB “boot” partition), you should run the boot loader repair function.

I hope that, from the above, you can work out whether or not it is doable or desirable to install GRUB onto your “Master Boot Record”. If you need any further information, just let me know.

luvr - thank you for the explanation. Now I better understand FSarchiver.

Regarding my computer setup:

Win7 on its own HDD. The 2nd HDD is NTFS format and only used for data storage.

My Linux is restricted to a removable, bootable 16 GB USB flash. I purposely do so because I want to separate the Windows boot from the Linux boot. Right now, my USB is on a higher boot priority than the Win7 HDD.

Thus: If I plug in the USB I go to Linux. If I don't have the USB then I go to Win7.

Knowing these setup details, would I still follow the same "experiment directions" you gave earlier?

Once again, thank you for your patience!

Hmmm... That opens up an interesting option: You could install GRUB onto the Master Boot Record of your second hard disk, and leave your Windows boot sequence intact. Assuming that your BIOS allows you to select the hard disk from which the system will boot (my BIOS provides this option), you can, then, experiment with GRUB on the Master Boot Record of the second hard disk. You will probably have to take some action in the BIOS whenever you want to select the boot disk, but as a fairly low-risk experiment, that should be doable.

Perhaps an interesting experiment might be, to boot Linux from your USB disk, and set up GRUB on the Master Boot Record of your second hard disk. Then, try to boot from the second hard disk, and see what happens. (Since the boot file system is on your USB device, you will have to leave that plugged in to ensure a successful boot.)

I certainly would not install GRUB on the Master Boot Record of your first hard disk, since, in your current setup, you would then no longer be able to boot from the hard disk without the USB device being plugged in (because the GRUB boot file system would sit on the USB device).

luvr - in the interest of simplicity, would it be possible to make a small "boot partition" on my flash device so I could boot directly from it? Currently, the flash has only 1 partition: Kubuntu 14.04 root.

My thinking is if I somehow isolate and protect "boot" in one partition and have the OS with root in another, then I could restore the OS at will without worrying about boot problems.

Yes, I think that should work. It would certainly keep the boot file system separate from the main root file system. You should, then, be able to restore the latter without disturbing the former.

How large of a partition would I need for boot? So far, my research shows only a very small size (a few MB) is needed.

I was thinking I could use gparted to shrink my /root enough for /boot. Would that work?

Indeed, a very small size is sufficient. When I create a separate boot partition, I usually size it at some 100 MB, which is much more than strictly necessary, but ensures that I will never run out of space on this critical partition.

And yes, you can perfectly use gparted as you note.