Quote:
Originally Posted by danost
I have several installs on one hard drive, so I've set things such that the boot info is in the MBR of the hard drive, not in a particular Linux install.
|
Are you using GRUB or GRUB2? Assuming GRUB, there's a nice explanation
here which describes how the MBR is only 446 bytes long so can do very little; it contains GRUB stage 1; when GRUB stage 1 is installed to the MBR it is configured with the block address of the file to load for the next stage of GRUB (stage 1.5 when the root file system is an "exotic" type, directly to stage 2 otherwise). This is why the usual advice is to "re-install GRUB".
A conventional arrangement is to have a single /boot file system for GRUB. It contains files the GRUB stages beyond 1 and the GRUB configuration, including "the boot info". For convenience the /boot file system can be mounted by all the installs, allowing you to read/modify it when they are running but it does not have to be this way -- just as long the file system used by GRUB is a "non-exotic" file system type (from GRUB's perspective).
The difficulty about backing up GRUB is that stage 1, in the MBR, needs to know the block address of the file for the next stage. If that file is restored by a file-level restore, it is unlikely to be put in the same place, that is at the same block address on the HDD.
In theory (not tested), one way to do this, assuming a separate /boot file system at the start of the drive, is a block level copy of the HDD from the beginning to the end of the /boot file file system using
dd. Normally
dd cannot be used to backup mounted file systems because they may be changing while they are copied and an inconsistent image would be recorded. In the case of the /boot file system this should (TM) not apply because it is only changed during kernel installs and GRUB customisation.
Such a block-level copy would also copy the partition table; if the partition table was changed between the copy and the restore then it would point to some wrong locations. In practice the chances of this happening could be mitigated (not eliminated!) by an automated backup run frequently or by sysadmin discipline to run the backup immediately after changing the partitions.