Restoring Backup data?

[Mantrid]

Hi all

I've been taking backups of my pi SD using dd, though I think I've been doing it wrong in that I've been backing up the main ext4 partition (sdb2) instead of the whole sd card (sdb), is that right?

anyway, I need to restore it now, thinking I can rewrite the base debian image and place the backup img over it and it'll magically write to the correct location as I thought it'd contain blocks etc, but apparently I was wrong because it fails to mount the main stuff altogether

I've tried mounting the image in ubuntu to at least recover the files inside but that doesn't work either (A long message saying some possible reasons, wrong fs type etc.) i'm away from the laptop now as I'm at work but can give any more details later if necessary, though I'm hoping this is a common thing that I just don't get cos I'm new at linux

Is there a simple way of extracting the files in an ext4 img without mounting? (I've tried acetone and it says it's either corrupt or an unsupported format) or failing that an easy way of copying it to the correct partition on the sd card after the main install image has been copied over?

I had it all set up beautifully and although it'll just be a matter of a few days to set up the basic configs again there is some code that I'd rather not have to rewrite from scratch if possible..

Sorry if I'm being vague, again I'm just hoping it's something easy that I've no idea about for being new...

Cheers

[GrahamC]

I presume you have tried:

sudo mount -o loop -t ext4 FILE MOUNT_POINT

where FILE is the name of your backed up file and MOUNT_POINT is the place to mount it at.

I believe fsck (or e2fsck) will work on a file as well as a device, so you could try

e2fsck -v FILE

to verify that the partition backup looks good.

Restoring a partition to a particular place on the SD card should work if the SD card partition table matches what it was when the backup was taken - so you would need to remember your original partition sizes and starting positions (or to have saved the first sector of the device in a backup file so that you have that information to hand).

[Mantrid]

Hi, thanks for replying

yes I use Gparted with the same values as when I set up the card initially (As it's a 4gb card so I'd resized the partitions to use it all and kept the steps I used in case I needed them again) so I repeated that when installing the base image again

I used that mount command but not with the -t ext4 option, I'll try that tonight, as well as the other command you've given, thanks again, I'll let the thread know how it goes

[AndrewS]

You can also point fdisk at a file instead of a device, to see what partitioning info it contains:
fdisk -l FILE

And you may find kpartx useful too.

[Mantrid]

fdisk says:

Code: Select all

Disk pi_4gb_2012_06_19.img: 3355 MB, 3355451392 bytes
255 heads, 63 sectors/track, 407 cylinders, total 6553616 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
Disk identifier: 0x00000000

Disk pi_4gb_2012_06_19.img doesn't contain a valid partition table

Trying to mount it returns this:

Code: Select all

owner@ubuntu:~$ sudo mount -o loop -t ext4 /home/owner/pi_4gb_2012_06_19.img /dev/sdc
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

owner@ubuntu:~$ dmesg | tail
[  740.024088] sr 1:0:0:0: CDB: Test Unit Ready: 00 00 00 00 00 00
[  740.024102] ata2.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
[  740.024104]          res 51/20:03:00:00:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
[  740.024108] ata2.00: status: { DRDY ERR }
[  743.001215] EXT4-fs (loop1): bad geometry: block count 832000 exceeds size of device (819202 blocks)
[  745.064029] ata2: link is slow to respond, please be patient (ready=0)
[  750.048037] ata2: device not ready (errno=-16), forcing hardreset
[  750.048050] ata2: soft resetting link
[  750.260285] ata2.00: configured for UDMA/25
[  750.268752] ata2: EH complete

e2fsck ends with "Either the superblock or the partition table is likely to be corrupt!"

[Mantrid]

Oh and if i dd it to either sdb or sdb2 it finishes up that the sd card only has 1 partition, that ext4 (which i can't mount anyway)

[GrahamC]

That error message from mount is the generic one it displays on pretty much any error condition. Not sure why you are mounting to /dev/sdc rather than somewhere in /media or /mnt but I doubt if it is getting far enough for that to be the issue.

Another command you can try is dumpe2fs pi_4gb_2012_06_19.img
to see if that can make any sense of the image file.

I believe there are some commercial programs for recovering data from a variety of partition types (including Linux file systems) but as far as I know they are all ones that have to be purchased, none are free.

[Mantrid]

Hm. Tried using the alternative superblocks and got the same message. Remembered I took a backup the previous day and that's working fine when i mount it!! all these messages saying it was corrupt must've actually been true rather than the pc trying to guess for once..dd'd it to SD and it's booting up awesomely too

I seem to have lost wireless connectivity, probably among a few other minor things, I'm assuming that would've been stored in the smaller partition when I set it up which wasn't the bit backed up?

Either way the problem's now solved, but as always it's an opportunity to learn about how the whole thing works, in this case what kind of data is stored in the 1st partition..

[AndrewS]

The first (smaller) partition just stores the bootloader (bootcode.bin, loader.bin), the optional bootloader arguments (config.txt), the GPU firmware (start.elf), the linux kernel (kernel.img) and the optional kernel command line (cmdline.txt).
Apart from the two text files, everything (collectively referred to as "the firmware") gets updated by rpi-update, so doing that may fix your wireless problems

[Mantrid]

Ah yeah that's a good point, I got my wireless working before by using the rpi-date actually. Also what you listed there may explain why all my scripts and servers are running but the terminal text on the tv before i put it back to headless was miniscule again

[RaTTuS]

what exactly did you type to back it up
and what did you type to restore

[Mantrid]

sdb is the whole sd card, sdb2 was the main partition

the command was something along these lines:

dd bs=1m if=/dev/sdb2 conv=sync,noerror | gzip -c > (location)

to restore was easy enough, just unzip and then run dd if=(location) of=/dev/sdb2

In the future though I'll know to do it to the whole SD card rather than that one partition

(I got the sd device name from df -h and then unmounting it with umount before making the image)

I think a saw a project when I was trying to solve this of someone who's making a script to auto backup from the pi itself or something though

[RaTTuS]

kk -
common errors when using dd is to put a partition back to the whole device - trashing the partition table
what you can do is make a dd of the partition table also
doing individual partitions is better IMO.

though TBH i use rsync to do filesystems

[Mantrid]

ha yeah I tried that as a last resort at one time but the pi wouldn't even boot for obvious reasons. when i used the dodgy image onto sdb2 it'd boot ok but when it was loading up it wouldn't be able to mount the main partition and just kernel panic, so i knew it was a bit closer to the solution but the only thing missing was that it was corrupt