How do I mount a partition on a "nested" back-up drive.

scott092707 · 01-22-2021, 07:31 PM

I use as main drive a 1TB SATA SSD, which has multiple OS partitions, and a data partition (plus swap and EFI partitions, of course)

Periodically, I back it up to 1 of two 1TB partitions on a 2TB SATA HDD.

Now, I wish to mount the data partition in one of the 2 back-up partitions, so that I may recover a browser profile directory (as mine just somehow got wrecked, and I no longer have my 12 windows and xxxx tabs (yes I know - bad housekeeping...), but just one window and no (1?) tab).

fdisk (and gdisk?) see that the partition resembles a real disk (with issues), and shows the partitions, but I cannot see how to get linux to mount the partition that is inside one of the partitions on the backup.

If all else fails, I can purchase a 1TB drive (and another SATA cable) and copy the relevant partition onto it, have gdisk "fix" it, and then mount it. I would rather avoid the expense, and the time waiting for it to arrive, if at all possible.

Short of that, is there some way of inducing linux to see a partition on the backup 2TB drive as an actual drive, so that I can mount a partition on it?

michaelk · 01-23-2021, 06:42 PM

Welcome to LinuxQuestions.

Post the output of lsblk -f command.

syg00 · 01-23-2021, 07:13 PM

Yes, significant lack of useful data for such a verbose post.
How are the backups done ?. I'm guessing dd from the actual system (while it is active) - hence the broken broken images. Linux has tools to mount valid images ok.
Have a look at the manpage for partx - it will allow you to list, and (maybe) mount the partition embedded in the image. Depends on how broken things are.

scott092707 · 01-24-2021, 08:30 PM

>I'm guessing dd from the actual system (while it is active) - hence the broken broken images.
No. gddrescue (dd under the hood, no doubt) from a live-USB.
The images are "broken" because despite the fact that it is a 2TB drive backing up a 1TB drive twice, there are apparently a few too few [M|K|-]bytes right at the end to finish copying.
There is no problem, because my data does not go anywhere near all the way to the end anyway, and if I needed to restore the drive, I can just gddrescue it onto another drive, and have gdisk fix it before use.

I posted here, because before doing so, I did not apparently phrase my search well enough to come up with solutions.
I since phrased it differently and found references to losetup, partx, and so forth.
So far, no joy.

I'll post the text of my various commands (yes, michaelk, including lsblk -f) in a code-block, if this forum has that feature, and also attach the text file, if that is possible.
[No, apparently I won't - it says "The text that you have entered is too long (31601 characters). Please shorten it to 30000 characters long."]

[I did this from a live-USB, because for some reason, when I attached my backup-drive, GRUB went to its commandline, and 'exit' just pauses, and then goes back to the command line... I don't know why - normally 'exit' just then goes to the boot menu...]

(One other thing I tried: something like: ~ sudo mount -o <whatever 244314112*512 turns out to be> /dev/sda2 /mountpoint),
but no joy there, either... (I cannot show the actual call/results, because my live-USB screensaver suspended, and then wanted a (non-existant) password to resume, and I had to reboot.)

Question, first:
Can gdisk be used to "fix" a "drive" on the partition containing an image, rather than a real disk?
I would hate to ruin the backup trying to point gdisk at a partition (although it DOES seem to see the partitions within the image).

In case anyone is interested, I'm using Debian Testing, with Sway 1.5
I did not think that this would be pertinent, or I would have mentioned it before.

rknichols · 01-25-2021, 08:12 PM

You can create a composite device which consists of /dev/sda2 padded out with zeros to at least the needed size. You should be able to mount that padded filesystem, though I suggest mounting it read-only and not using fsck to repair it unless the mounting still fails.

Code:

echo -e "0 1953513472 linear /dev/sda2 0 \n 1953513472 8192 zero" | dmsetup create padded
mount -r -o $((244314112*512)) /dev/mapper/padded /mountpoint

Note: that "8192" is $((1953521663+1-1953513472))

If the mount command insists that the filesystem be repaired first, you will need to create another volume that contains just the filesystem:

Code:

echo "0 1953521664 linear /dev/mapper/padded 244314112" | dmsetup create pad2
fsck /dev/mapper/pad2

This fsck really should be done only on a copy of /dev/mapper/pad2 since the repair effort can sometimes make a bad situation unrecoverable. It's your data, your choice.

Note that the allocation strategy for many filesystems deliberately distributes files among all the block groups of the filesystem, so some of your data could still be near the end of the device, probably not in that last 2 megabytes though.

To clean up:

Code:

dmsetup remove pad2  #If necessary
dmsetup remove padded

BTW, the problem with your 31601-character file is that lines were padded out to ~420 characters with spaces. I have no idea how that could have happened, and I don't really want to know.

syg00 · 01-25-2021, 08:18 PM

Thanks again - I really didn't want to have to try to explain that to anyone.

scott092707 · 02-28-2021, 05:03 PM

I'm sorry not to have replied earlier with the final disposition of my issue.

Your kind suggestions did not work for me, unfortunately.

I ended up copying the newer backup (2nd partition) over the older, deleting the 2nd partition, using parted to increase the size of the partition by ~12000 sectors and successfully used gdisk on the partition to copy the good gpt info from the front of the "drive" to the end.

Once that was done, I was able to:

Code:

user@debian:~$ sudo /usr/sbin/losetup -P -f -v --show /dev/sda1
/dev/loop1

user@debian:~$ sudo fdisk -l /dev/loop1
Disk /dev/loop1: 931.53 GiB, 1000205041664 bytes, 1953525472 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: gpt
Disk identifier: E1ECFEC6-A297-4DC2-ADF3-37DEB7895D97

Device            Start        End    Sectors  Size Type
/dev/loop1p1       4096    1052671    1048576  512M EFI System
/dev/loop1p4    1052672   34605055   33552384   16G Linux swap
/dev/loop1p5   34605056   76546047   41940992   20G Linux filesystem
/dev/loop1p6   76546048  118487039   41940992   20G Linux filesystem
/dev/loop1p7  118487040  160428031   41940992   20G Linux filesystem
/dev/loop1p8  160428032  202369023   41940992   20G Linux filesystem
/dev/loop1p9  202369024  244310015   41940992   20G Linux filesystem
/dev/loop1p10 244314112 1953521663 1709207552  815G Linux filesystem

user@debian:~$ sudo mount -t ext4   /dev/loop1p10     /bu_data

and was then able to copy out the data I needed.

Thank you very much for trying to solve my problem.

[I wish at the start I had somehow known that a 2TB drive was not NECESSARILY large enough to make 2 1TB backups.
I don't suppose one can ever tell the ACTUAL size at time of purchase...]

michaelk · 02-28-2021, 05:31 PM

The drive manufactures typically label the drive size using base 10.

A 2 TB disk is really only 1.8 Tib

https://en.wikipedia.org/wiki/Gigabyte

rknichols · 02-28-2021, 08:44 PM

Even without the issue of TB vs. TiB, partitioning the drive does use up a small amount of space, so you won't quite be able to fit two 1.000TB images in partitions on a 2.000TB drive. Also, drives are never exactly their nominal size. They are always slightly larger. So even without the partitioning overhead, two slightly-larger-than 1.0TB images might well not fit on your slight-larger-than 2.0TB drive.

scott092707 · 02-28-2021, 08:44 PM

>A 2 TB disk is really only 1.8 Tib
OK. then
a 1 TB disk is really only .9 TiB, and one would STILL think two of these would fit on the other...