How to restore partition table from DD Openmediavault-Backup

  • Hello,


    I made a DD backup of my system running on a usb stick using the Openmediavault-Backup plugin.
    Unfortunately I fail to restore the created backup to a second usb stick.


    Similar to this this thread I successfully created and restored backups of the entire block device using the following method.
    To backup:
    dd if=/dev/sdb of=/mnt/backupcopy.iso bs=4MB


    To restore:


    dd if=/mnt/backupcopy.iso of=/dev/sdc bs=4MB



    From what I understand the mbr and partition table are stored in the .grubparts backup file and can be restored with


    dd if=backup-omv-09-Aug-2019_15-46-32.grubparts of=/dev/sdg bs=512 count=1
    creating the mbr and partition table.


    After running the above command, sudo fdisk -l /dev/sdg displays the following output:


    Which is different from my original system drive:


    I tried to restore the system backup using
    gunzip -c backup-omv-09-Aug-2019_15-46-32.dd.gz | sudo dd of=dev/sdg1 bs=1M
    which crashes with the error
    dd: failed to open 'dev/sdg1': No such file or directory



    I would be grateful for any advice on how to restore the backup properly :)


    Edit:
    I am using OMV4.
    Editing the thread label and tags results in the following error:


    The server encountered an unresolvable problem, please try again later.


    Exception ID: 93d04f09014b98263e88391a166c94ddd535d4c7

  • Your procedures were correct. The only way it could've restored the partition table it did is if it backed up the wrong drive.


    Editing the thread label and tags results in the following error:


    The server encountered an unresolvable problem, please try again later.


    Exception ID: 93d04f09014b98263e88391a166c94ddd535d4c7

    Read problem #4 here - https://forum.openmediavault.o…tions-to-common-problems/

    omv 5.5.6 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • This is strange. I tried again and checked the log of omv-backup.


    The detected root drive seems correct:


    Do you have an idea what I could be doing wrong? Thank you for your help

  • Device file: /dev/sdd2
    Root drive: /dev/sdb

    Here is the problem. It is detecting your root drive as /dev/sdb when it should be /dev/sdd.


    What is the output of:


    cat /proc/self/mountinfo
    findmnt -n /

    omv 5.5.6 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • You're right! I completely overlooked that. Thank you :)


    findmnt -n /

    Code
    / /dev/sdd2 ext4 rw,relatime,errors=remount-ro

    cat /proc/self/mountinfo


  • cat /proc/self/mountinfo cont

    Code
    191 25 0:58 / /var/lib/docker/containers/4929dbc6f4ec13fcd09124992c82af2dc2787bab3240dd15926e82b323f1dd9a/mounts/shm rw,nosuid,nodev,noexec,relatime shared:46 - tmpfs shm rw,size=65536k
    193 25 0:59 / /var/lib/docker/containers/30163f8a94ec20254d41c7c3c670d1dd4b49a1d7dd1931d0f74d18472d4a1aaf/mounts/shm rw,nosuid,nodev,noexec,relatime shared:47 - tmpfs shm rw,size=65536k
    195 25 0:60 / /var/lib/docker/containers/c6fc57190d6027b7212079c9f755a82c6b2f1a5b6d4a50bf51708b05ac2bab08/mounts/shm rw,nosuid,nodev,noexec,relatime shared:48 - tmpfs shm rw,size=65536k
    197 25 0:61 / /var/lib/docker/containers/898606b63f21c78cf13f1608422b87769544590a511c79b28c35a3bed55baebd/mounts/shm rw,nosuid,nodev,noexec,relatime shared:49 - tmpfs shm rw,size=65536k
    199 25 0:62 / /var/lib/docker/containers/9ffe64d396cc90ab93bb157ccbd1c414d43b5b5c48fa86936e8377827ccf0f12/mounts/shm rw,nosuid,nodev,noexec,relatime shared:50 - tmpfs shm rw,size=65536k
    659 24 0:3 net:[4026532596] /run/docker/netns/8ba5b2d3e0ac rw shared:51 - nsfs nsfs rw
    666 24 0:3 net:[4026532522] /run/docker/netns/7f7f159cebf6 rw shared:52 - nsfs nsfs rw
    673 24 0:3 net:[4026532666] /run/docker/netns/5ff3085183dd rw shared:53 - nsfs nsfs rw
    680 24 0:3 net:[4026532331] /run/docker/netns/4950eebfae11 rw shared:54 - nsfs nsfs rw
    687 24 0:3 net:[4026532345] /run/docker/netns/42039efe3218 rw shared:55 - nsfs nsfs rw
  • cat /proc/self/mountinfo cont

    Did you change the Root device field to /dev/sdb in the plugin? I can't think of any other way this happening.

    Thank you! That was indeed the mistake I made.


    Strangely though
    sudo dd if=backup-omv-12-Aug-2019_23-34-12.grubparts of=/dev/sdf bs=512 count=1
    still does not create the partitions properly

  • still does not create the partitions properly

    So, you removed any text from the root device field, took another backup, and tried writing the file to another drive? The plugin is just doing simple dd commands. Unless it is reading from the wrong drive, there is nothing that can wrong with this process.

    omv 5.5.6 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • So, you removed any text from the root device field, took another backup, and tried writing the file to another drive?

    Correct.


    And you're also correct about the plugin not being at fault.
    If I understand correctly
    sudo dd if=/dev/sdd of=/dev/sde bs=512 count=1
    should copy the partition layout from my root device to sde.
    That doesn't happen as you can see below.

    Unfortunately I don't have another ≥16 GB drive at hand to test the command. I tried to copy the partition layout to another 4 GB but that didn't work either.


    As long as the command should do what I believe it should, I don't know what external condition could prevent it from working.


    Copying the devicefile afterwards with
    sudo dd if=/dev/sdd2 bs=1M conv=sync,noerror status=progress of=/dev/sde2
    does not work either.

  • /dev/sde is not mounted.
    sudo partprobe -s /dev/sde returns
    /dev/sde: loop partitions 1


    lsblk still shows

  • sudo partprobe -s /dev/sde

    Why did you change the command? I didn't want a summary. I wanted to rescan the partition tables. If that doesn't fix it, I don't know what is wrong. I've never seen dd say it wrote blocks and not really write them. Bad usb stick?

    omv 5.5.6 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

  • I'm sorry. I also ran sudo partprobe but lsblk didn't show any changes in the partition layout.


    I will try to get my hands on another usb stick than. I checked the usb stick running omv and the stick used to restore the backup with f3write though, which didn't show any problems.


    Can the previous filesystem or partition table of the usb stick influence dd?

  • I found the problem!


    It was in hindsight ofc logical and simple. My boot device is using a GPT instead of a MBR partition table, which occupies a bigger block of data at the start of my devices.


    Following this advice, I calculated the size of my partition table as follows
    size=(128*N)+1024,
    where N is the number of partitions on the device.


    In my case I have three partitions and thus can backup my partition table using


    sudo dd if=/dev/sdd of=partition-table.grubparts bs=1 count=1408
    and restore it using
    sudo dd if=partition-table.grubparts of=/dev/sdb bs=1 count=1408


    Do you think it would be a good idea to expand the backup script to detect GPT and backup accordingly?
    As I'm still on vacation I haven't tested the complete backup yet and will report as soon as I've recovered a complete backup successfully.

  • Do you think it would be a good idea to expand the backup script to detect GPT and backup accordingly?

    Maybe. I never worried about it because the OMV installer doesn't use GPT for the system disk.

    omv 5.5.6 usul | 64 bit | 5.4 proxmox kernel | omvextrasorg 5.3.5
    omv-extras.org plugins source code and issue tracker - github


    Please read this before posting a question.
    Please don't PM for support... Too many PMs!

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!