Retrieving Files From Dd Backup

Home » CentOS » Retrieving Files From Dd Backup
CentOS 5 Comments

Running CentOS 7 I have a previously combined backup of a disk with three partitions using dd. I now need to restore one single file from this backup and after perusing the internet, specifically https://unix.stackexchange.com/questions/31669/is-it-possible-to-mount-a-gzip-compressed-dd-image-on-the-fly, I have done the following:

– installed squashfs-tools

– installed kpartx

– made a squash image of the dd backup and mounted it

– used kpartx to create devices for the three partitions under /dev/mapper/loopNpP

– I can now mount the first partition, which is the EFI partition, and access it

– the second partition, the boot partition, fails to mount since it has the same UUID as the disk I am using in the computer, and of which it is an earlier dd backup. Since I am not interested in the boot partition – at least not right now – I moved on.

– I am, however, interested in the third partition which is LUKS encrypted. Running ‘cryptsetup luksOpen /dev/sda3 my_encrypted_volume’ I can decrypt it with the password

– trying to mount the decrypted version with ‘mount /dev/mapper/my_encrypted_volume /media/my_device’ results in a failure message ‘mount: unknown filesystem type ‘LVM2_member’

– another website, https://askubuntu.com/questions/766048/mount-unknown-filesystem-type-lvm2-member, suggests I could run vgdisplay to get the UUID and then rename it using vgrename

But, vgdisplay shows only one vg and I am afraid to rename the VG UUID shown by vgdisplay since it might refer to the VG currently in use…

Does anyone have any insight or suggestions into the above and how to proceed while being absolutely certain I will not be messing up the running part of the system?

Thanks!

5 thoughts on - Retrieving Files From Dd Backup

  • Am 26.11.20 um 20:10 schrieb H:

    IIRC: Activate the LVM via: vgchange -a y

    and mount the logical volume (LV).

    LV can be listed with lvs. The device nodes are under /dev/mapper …

  • OK, I am looking at https://www.cyberciti.biz/faq/linux-mount-an-lvm-volume-partition-command/. A couple of follow-up questions:

    – Would activating the LVM with ‘vgchange -a y’ make any changes, or create any potential issues, with the system already running?

    – How do I know that the output from ‘vgdisplay’ refers to this ‘new’ VG and not VGs on the running system?

    – To mount the VG, I would have to run:

    — ‘vgscan’

    — make directory for mounting

    — ‘mount…’ to mount the VG

    Is that correct? And it would not create any issues with the running system?

    Thank you in advance.

  • Simple question did you try a CentOS live cd with a all tools to open the system?
    Perhaps the easiest way when not trained every day restoring files. Ralf

    Von meinem iPad gesendet

  • No, for two reasons. One, I am not trying to restore the entire system, only one file from the dd backup. Second, this is also a training run for the future.

  • OK, finally had time to delve into this and become a LVM expert (ha!) I got it working and can retrieve files from old dd images, both unencrypted and LUKS encrypted. Note that I did this on another computer than the dd images were made from to avoid UUID conflicts.

    However, a couple of questions:

    Section 1:

    I had no problems mounting and accessing the files for the boot partition but since the home partition is a “LVM2_member”, I had to go through some extra steps such as:

    “vgimportclone –basevgname -i /dev/mapper/mev” (the latter location is an arbitrary name chosen by me)

    This results in error message:

    “Error writing device /dev/mapper/mev at 4096 length 512.
      bcache_invalidate: block (6, 0) still dirty
      Failed to write mda header to /dev/mapper/mev fd -1”

    Question 1:

    – What does this error message really mean? Is this something I ought to fix (although I blithely continued as below…)

    Section 2:

    However, after running lvscan, vgchange -ay, ls -lh /dev/mapper to find out which /dev/dm-* to mount (/dev/dm-7) in my case:

    “mount -o ro,loop /dev/dm-7 mtb3” (the latter again is a mount point arbitrarily chosen by me)

    Results in another error message about a missing superblock which could be corrected by:

    “mount -o ro,loop,norecovery /dev/dm-7 mtb3”

    I was then able to recover the couple of files I needed.

    Question 2:

    – Should I do something different when eventually mounting to avoid the error message about a missing superblock? Or is there something wrong with the disk partition I had copied by dd?

    Looking forward to insight by those more knowledgeable than myself.

    Many thanks.