| View previous topic :: View next topic |
| Author |
Message |
ckoeber
Apprentice
Joined: 21 May 2007
Posts: 156
|
 Posted: Tue Feb 07, 2012 11:20 pm Post subject: Recovering MySQL Database from EXT4 Formatted Hard Disk ... |
 |
|
Hello,
I am trying to recover MySQL databases (which were properly shut down) from an EXT4 formatted hard disk. I loaded the SystemRescueCD distro that you can get online and when running TestDisk I can see the partitions but I cannot recover said partitions because it tells me the structure is bad (any options here, by the way?)
With PhotoRec, I can recover parts of the MySQL Database but I cannot get the important *.MYD files because I guess PhotoRec doesn't have the signatures for that type of file.
So, any options I have at this point?
Thank you for your time. |
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54236
Location: 56N 3W
|
| Posted: Tue Feb 07, 2012 11:46 pm Post subject: |
|
|
ckoeber,
Given the start addresses for the filesystem(s) its possible to attempt to mount them usinag alternate superblocks.
You need loop support in the kernel and you need to know where the alternate superblocks are
The hard bit is finding the filesystem start blocks on your disk - but testdisk should have told you that.
Read and
The mount command you want, ignoring any partition table on the disk is
| Code: | | mount -o loop,ro,offset=<bytes> -t ext4 /dev/sdX /mnt/someplace |
where <bytes> counts from 0 at the start of the drive and is normally blocks*512.
Its sdX and not sdx1 as we are ignoring the partition table
The ro == read only - thats essential. Writing on a suspect filesystem,even accidently is a really bad idea
The above command does not try an alternate superblock, thats another option. sb=<block> where block is a block count from the start of the filesystem.
Again - trial and error is harmless. The man pages will give you some ideas of numbers to try for alternate superbloacks.
If you get the numbers wrong, mount will fail but no damage will be done.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
ckoeber
Apprentice
Joined: 21 May 2007
Posts: 156
|
| Posted: Wed Feb 08, 2012 6:27 pm Post subject: |
|
|
Thanks so much for this reply. Certainly worth a shot. The only problem I am having is calculating the offset you have below. Do I multiply the "Starting Block" by 512?
Here is my TestDisk output below:
| Code: |
TestDisk 6.12, Data Recovery Utility, May 2011
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
Disk /dev/sdb - 136 GB / 127 GiB - CHS 16579 255 63
Partition Start End Size in sectors
>D Linux 32 97 2 15551 254 63 249322688
D Linux 143 171 29 15662 254 63 249317999
|
What would a good value to use for "bytes" in this instance?
Thanks. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54236
Location: 56N 3W
|
| Posted: Wed Feb 08, 2012 7:39 pm Post subject: |
|
|
ckoeber,
Thats Testdisk reporting its finding in Cylinder/Head/Sector notation.
From the end addresses we can tell that its assuming 255 heads and 63 sectors per track.
The line | Code: | | Disk /dev/sdb - 136 GB / 127 GiB - CHS 16579 255 63 |
is a little worrying. The 136 GB / 127 GiB is an old BIOS limit, or more exactly, the old Logical Block Addressing limit.
How big is the drive really? will show that. It will also show the current partition table if there still is one.
To save me some writing, see the gory details.
The important bit is
| Code: | | LBA = ( (cylinder * heads_per_cylinder + heads ) * sectors_per_track ) + sector - 1 |
For your case | Code: | | LBA = ( (cylinder * 255 + heads ) * 63 ) + sector - 1 |
Plug your numbers in, calculate the LBA then offset=LBA*512
Traditionally, the first partition on MSDOS Partitionined drives has always been C=0, H=1 S=0, which maps to logical block 63, or byte 32256 on drives that fake C/H/S addressing. Thats every drive over 2G.
Regardless of what testdisk has to say, its worth trying offset=32256 as the first partition should be there.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
ckoeber
Apprentice
Joined: 21 May 2007
Posts: 156
|
| Posted: Thu Feb 09, 2012 12:01 am Post subject: |
|
|
Thanks for your reply.
To answer the immediate concern about the size of the disk, yes, it is correct. The drive was a virtual disk that has that limitation (137 GB max on the drive).
Here is the output of fdisk -l /dev/sdb:
| Code: |
Disk /dev/sdb: 136.4 GB, 136363130880 bytes
255 heads, 63 sectors/track, 16578 cylinders, total 266334240 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: 0xffffffff
Disk /dev/sdb doesn't contain a valid partition table
|
As for the calculations, I reviewed both the document and what you wrote and attempted to perform the mount but the mount didn't work.
Here is what I came up with for the corresponding offsets for each partition as listed by testdisk:
For this one:
| Code: | | >D Linux 32 97 2 15551 254 63 249322688 |
I used the following calculation:
| Code: | | 2/8/2012 6:57:21 PM - Calculation: (Cylinders:32 * 255 + Heads:97 ) * 63 + Sector:2 - 1 = LBA Address: 520192 |
And for this partition:
| Code: | | D Linux 143 171 29 15662 254 63 249317999 |
I used:
| Code: | 2/8/2012 6:57:48 PM - Calculation: (Cylinders:143 * 255 + Heads:171 ) * 63 + Sector:29 - 1 = LBA Address: 2308096
|
Is that right?
Also, I was thinking if it would be a good/bad idea to just right some sort of script that keeps attempting a mount by incrementing the offset and then stopping once there was a successful mount.
Thoughts?
Thanks again. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54236
Location: 56N 3W
|
| Posted: Thu Feb 09, 2012 7:45 pm Post subject: |
|
|
ckoeber,
An exhaustive search that way will be slow but its safe.
Can you remember hwo the drive was formatted when it used to work?
Your LBA numbers look right - then you multiply by 512 to get bytes for the offset=
What did mount tell you?
| man mount: | sb=n Instead of block 1, use block n as superblock. This could be
useful when the filesystem has been damaged. (Earlier, copies
of the superblock would be made every 8192 blocks: in block 1,
8193, 16385, ... (and one got thousands of copies on a big
filesystem). Since version 1.08, mke2fs has a -s (sparse
superblock) option to reduce the number of backup superblocks,
and since version 1.15 this is the default. Note that this may
mean that ext2 filesystems created by a recent mke2fs cannot be
mounted r/w under Linux 2.0.*.) The block number here uses 1k
units. Thus, if you want to use logical block 32768 on a
filesystem with 4k blocks, use "sb=131072". |
Its a lille misleading as thats under ext2 but it applies to ext4 too.
Keep in mind how you specify sb=
| man mke2fs: | -b block-size
Specify the size of blocks in bytes. Valid block-size values are 1024, 2048 and
4096 bytes per block. If omitted, block-size is heuristically determined by the
filesystem size and the expected usage of the filesystem (see the -T option). If
block-size is preceded by a negative sign ('-'), then mke2fs will use heuristics
to determine the appropriate block size, with the constraint that the block size
will be at least block-size bytes. This is useful for certain hardware devices
which require that the blocksize be a multiple of 2k. |
Most extX filesystems use 4k block because partitions as so big. You can force other numbers as you can see.
Taken together sb=131072 is a good number to use for an alternate superblock, as 4k blocks are very likely.
This gives us a mount command something like, | Code: | | mount -t ext4 -o loop,ro,sb=131072,offset=<bytes> /path/to/file /mnt/someplace |
You mentioned that the drive was a virtual disk. That may be important. Some but not all VMs prepend data to the front of their virtual disks, that messes up the offset.
Can you post the first sector or two of the file as seen in hexedit?
If not, email me the first chunk of the file | Code: | | dd if=/path/to/input of=~/nedddy.img bs=512 count=2048 |
Then email me the file ~/nedddy.img
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
