Restore Amanda SD card backup - data partition not restored

Setup, Configuration and Use Beginners
1

Continuing the discussion from [SOLVED] Restore Amanda backup:

Hello, not sure if relating to this this oldtopic is appropriate, but the topic header fits for my problem, and I know @mstormi is certainly the expert.
I have successfully installed Amanda (OH3.3 / bullseye. / openhabian ) and I am able to do backups form individual files to my Synology NAS.
Moreover, I can do backups of the SD card by adding the mmcblk0 device into the config, which results in a compressed image file, which can also be restored by the amfetchdump command to an SD image file of the old size - all without error message.
The problem is: if I write the image file back to SD card and try to mount it, there is only one partition visible, which does not contain any files or data.
Here is what I get if I try to mount the image file to a loop device (as proposed in the old post):

wille@wille-Linux:~$ fdisk -l  test_shrink.img
Festplatte test_shrink.img: 8,5 GiB, 9130746368 Bytes, 17833489 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0xb618c86c

Gerät            Boot Anfang     Ende Sektoren Größe Kn Typ
test_shrink.img1        8192   532479   524288  256M  c W95 FAT32 (LBA)
test_shrink.img2      532480 17833488 17301009  8,2G 83 Linux
wille@wille-Linux:~$ mount -o ro,loop,offset=532480 test.img /mnt/temp
mount: /mnt/temp: das Loop-Gerät für test.img konnte nicht eingerichtet werden.
 
wille@wille-Linux:~$ mount -o ro,loop,offset=532480 test_shrink.img /mnt/temp
mount: /mnt/temp: das Loop-Gerät für /home/wille/test_shrink.img konnte nicht eingerichtet werden.

wille@wille-Linux:~$ sudo losetup --offset 532480 /dev/loop20 test_shrink.img

wille@wille-Linux:/mnt/temp$ sudo mount /dev/loop20 /mnt/temp
mount: /mnt/temp: Falscher Dateisystemtyp, ungültige Optionen, der Superblock von /dev/loop20 ist beschädigt, fehlende Kodierungsseite oder ein anderer Fehler.

As you see, the fdisk check shows two partitions in the original file, which seems reasonable,

In all my attempts by the dd command, only the small one at the beginning is restored (the same for a windows card writer).
Consequently, when I try to boot from the SD card, nothing happens.
Does anyone have an idea, what is going wrong here?
Is there something wrong with the configuration of Amanda, when the full card backup is written?

2

in a second attempt, after setting up Amanda from scratch, I wrote the restored image file to SD card with the dd command including the option “bs=4M”, which is shown in an example of the readme file. In the first test the block size was not specified.
This made a difference, now both partitions are restored correctly, which is great.
Maybe somebody can check if my suspicion is correct, that the wrong blocksize caused the problem. If this is correct, it should be mentioned in the readme file more explicitly.

3

Glad your restore worked now, but why don’t you validate your “suspicion” yourself and expect someone else to do that work for you ?

4

as I said, I did a completely new setup, and will never be sure to have the same situation again.
But it works now, so nobody has to do anything “for me”.
I just wanted to give a hint that missing block size could be a reason for trouble, I spent already too much time with this issue.
thank you anyway.

[Edit Jan. 23]:
in a new attempt for a test of the restore function, I tried restoring the image by the dd command to a SD card with a slightly smaller usable capacity. Without error message, this resulted in a card image with both partitions seemingly correct, but not booting in the raspi.
After that, I used pi-shrink to create a smaller image and this time, the card booted successfully.

I did not use the blocksize command in the dd command, so I think my original suspicion was not correct, but one has to be careful to use a fresh card which is larger than the original image, or one has to use a tool like pishrink to fix this problem.

5

This is a joint open source effort that lives from everybody to contribute whatever he or she can, and surely you can by reproducing your issue: restore it using different block sizes to find out if your bs=4M solution needs to be used or not for things to work, then update the docs pages with your findings.