Skip to main content

Restore Eufi Disk in a Empty Disk

Thread needs solution

Hi,

We are using Acronis Backup & Recovery 11.5 to make a backup of a Linux system on a GPT partitioned disk.
We make the backup of the full disk, and we restore the full disk, not partition by partition.

After the restoration, the system is unable to boot. Inspecting the content of the disk, we see that the partions are there, but as msdos/MBR partitions, instead of GPT partitions as it should be.

Booting with a Linux rescue CD, and converting the disk from MBR to GPT with ‘gdisk’ fixes the problem, and the computer boots ok.

¿ Is Acroing going to fix this issue ?
Having our field technicians using Linux for making the deployment is not and ideal solution, and we have read that other products like parangon or Macrium restore to GPT without problem.

Regards,

Endika

0 Users found this helpful

I have been playing around with a some parameters, and made more than 30 restore tests.

Here are the parameters I played with:
. The content of /etc/fstab before creating the image
. The “NT Signature” option used during restauration
. The initial content of the HDD (completely empty, valid installations, invalid installations)

I can always manually fix the restored system, but it’s quite random, and don’t know how to make it to be used in a production environment with a not very skilled user.

Sometimes the first sectors)of the disk are corrupt, not always the same type of corruption.
By the way, I have seen that the Acronis Terminal has algo ‘gdisk’ utility, so I don’t need to boot with an external live linux to fix it, cool.

When the first sectors are OK, sometimes the system boots in emergency mode, it seems Acronis changed partially the UUIDs in /etc/fstab, but not for all partitions, and you need to do it manually.

Even if before doing the image you change ‘/etc/fstab’ to remove any UUID reference, and use ‘/dev/sdYX’ notations, when you restore, you see again UUID references. Sometimes pointing to the UUID before the restoration, sometimes to the actual UUID after the restoration.

¿ Any hint to have predictable results ?

Hello Endika,

Normally, a conversion shouldn't take place unless you are restoring from UEFI systems to BIOS systems.

What you are describing seems like a conflict specific to your hardware (something is not detected correctly) or with the specific OS (our product conflicts with the boot information/grub config/something else).

Due to the sector corruption, it could also be a bad RAM issues (this is the cause for 95%+ of corruption during backup/restore).

Does this same issue reproduce on different hardware with different system images?

Thank you.