I am trying to perform a zero-copy disk image restore so I can boot an image backup. I have done this a number of times previously but in this instance, I am trying to restore the mbr and I get this output:
2019-07-29 10:37:30: Writing MBR data…
2019-07-29 10:37:30: done.
2019-07-29 10:37:30: Writing GPT header…
2019-07-29 10:37:30: Writing GPT table…
2019-07-29 10:37:30: Writing GPT backup header…
2019-07-29 10:37:30: ERROR: Writing GPT backup header failed. No space left on device (code: 28)
2019-07-29 10:37:30: Writing GPT backup table…
2019-07-29 10:37:30: ERROR: Writing backup GPT table failed. No space left on device (code: 28)
GPT backup header goes to the end of the disk. So you either ignore the error message (it works without backup header) or make the mbr.img file at least as large as the whole disk.
Makes sense. When I ignore the errors and use parted to examine the partition table, there is no data and I get errors about a corrupt backup gpt header which clearly isn’t there. But I expected to see the partition data from the main gpt header.
Here is the output of parted on /dev/loop0 after I run the urbackuprestoreclient command:
parted /dev/loop0
GNU Parted 3.2
Using /dev/loop0
Welcome to GNU Parted! Type ‘help’ to view a list of commands.
(parted) p
Error: Invalid argument during seek for read on /dev/loop0
Retry/Ignore/Cancel? i
Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used.
OK/Cancel? OK
Model: Loopback device (loopback)
Disk /dev/loop0: 20MB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
(parted)
Is the mbr corrupt on this one?
This is what fdisk sees:
Command (m for help): p
Disk /dev/loop0: 20 MiB, 20971520 bytes, 40960 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x64371574
Device Boot Start End Sectors Size Id Type
/dev/loop0p1 1 4294967295 4294967295 2T ee GPT
The source server for this backup is a physical Win 2016 server.
With the help of gdisk I am able to see the gpt layout.
Disk /dev/loop0: 40960 sectors, 20.0 MiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 3B6E1B51-C04F-4388-A7A9-F854A76D0262
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 1952427998
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 1026047 500.0 MiB EF00 EFI system partition
2 1026048 1107967 40.0 MiB FFFF Basic data partition
3 1107968 1370111 128.0 MiB 0C01 Microsoft reserved …
4 1370112 7661567 3.0 GiB 2700 Basic data partition
5 7661568 1952425983 927.3 GiB 0700 Basic data partition
My question now is urbackup creates an ESP image file, a SYSVOL image file and then the C image file. Based on this partition map, I am not sure which partition/sectors the image files should associate with so that I can stitch them together with linux device manager in order to boot with kvm.
Can anyone help shed some light on this for me? Even some terms to search or links to references would be helpful!
But then I saw this post which says disk assembly doesn’t support GPT formatted disks.
Am I able to do a zero copy image creation so that I can boot this GPT formatted disk without taking the time to restore the data to a new image? I am using ZFS for storage. I am trying to boot in KVM not trying to do a bare metal restore.
The disk assembling doesn’t implement GPT reading, that’s why it can’t assemble the disk. In the zero copy case you read the GPT manually (via parted etc.), so it should work if you put everything in the correct locations. If you want to see how it is done, check out https://www.infscape.com/urbackup-appliance-download/ and look at how disks are assembled there for VMs.