If a system was bootable at the time of backup, you expect that it will boot after recovery. However, the information the operating system stores and uses for booting up may become outdated during recovery, especially if you change volume sizes, locations or destination drives. Acronis Backup & Recovery 11 automatically updates Windows loaders after recovery. Other loaders might also be fixed, but there are cases when you have to re-activate the loaders. Specifically when you recover Linux volumes, it is sometimes necessary to apply fixes or make booting changes so that Linux can boot and load correctly.
Below is a summary of typical situations that require additional user actions.
Why a recovered operating system may be unbootable
Solution: Configure the BIOS to boot from the HDD where the operating system resides.
Solution: Boot the machine using bootable media and apply Acronis Universal Restore to install the appropriate drivers and modules.
Solution: Recover Windows to a basic, simple or mirrored volume.
When you configure recovery of a system volume to a disk that does not have an MBR, the program prompts whether you want to recover the MBR along with the system volume. Opt for not recovering, only if you do not want the system to be bootable.
Solution: Recover the volume once again along with the MBR of the corresponding disk.
Because the Master Boot Record (MBR) can be changed during the system recovery, Acronis OS Selector, which uses the MBR, might become inoperable. If this happens, reactivate Acronis OS Selector as follows.
Solution: Boot the machine from the Acronis Disk Director's bootable media and select in the menu Tools -> Activate OS Selector.
One part of the GRUB loader resides either in the first several sectors of the disk or in the first several sectors of the volume. The rest is on the file system of one of the volumes. System bootability can be recovered automatically only when the GRUB resides in the first several sectors of the disk and on the file system to which direct access is possible. In other cases, the user has to manually reactivate the boot loader.
Solution: Reactivate the boot loader. You might also need to fix the configuration file.
LILO contains numerous references to absolute sector numbers and so cannot be repaired automatically except for the case when all data is recovered to the sectors that have the same absolute numbers as on the source disk.
Solution: Reactivate the boot loader. You might also need to fix the loader configuration file for the reason described in the previous item.
This may happen when system or boot volumes are not recovered to their original location.
Solution: Modification of the boot.ini or the boot\bcd files fixes this for Windows loaders. Acronis Backup & Recovery 11 does this automatically and so you are not likely to experience the problem.
For the GRUB and LILO loaders, you will need to correct the GRUB configuration files. If the number of the Linux root partition has changed, it is also recommended that you change /etc/fstab so that the SWAP volume can be accessed correctly.
Such system cannot boot because its kernel tries to mount the root file system at the LVM volume.
Solution: Change the loader configuration and /etc/fstab so that the LVM is not used and reactivate the boot loader.