I am trying to recover data from an old Buffalo Terastation that failed. A previous attempt to recover the data by someone else was unsuccesful and I have been left with the following situation.
NB: I am not sure exactly what commands have been run previously, hopefully nothing that has done permenant damage!
The original Terastation had four disks each with system, swap and data partitinons. The data partitions were managed using raid5 and I believe the file system was XFS.
Three of the data partitions have been copied to another device by connecting them individually in an external USB HDD device with a command something like:
dd if=/dev/sdd3 of=/share/disk1_data
Using mdadm --examine on the newly created backups yields the following:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : deb4c6d2:c2fc193c:a9599de3:a25d0d2c
Name : it:0 (local to host it)
Creation Time : Tue Sep 8 08:59:06 2015
Raid Level : raid5
Raid Devices : 4
Avail Dev Size : 779677543 (371.78 GiB 399.19 GB)
Array Size : 1169515008 (1115.34 GiB 1197.58 GB)
Used Dev Size : 779676672 (371.78 GiB 399.19 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
Unused Space : before=262056 sectors, after=871 sectors
State : clean
Device UUID : 2eed9b35:6857b6fa:00a76842:9f5ab0ae
Internal Bitmap : 8 sectors from superblock
Update Time : Tue Sep 8 09:40:17 2015
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 21f8a2ff - correct
Events : 8
Layout : left-symmetric
Chunk Size : 512K
Device Role : Active device 0
Array State : AAA. ('A' == active, '.' == missing, 'R' == replacing)
Each device has a different Device UUID, Checksum (each correct) and have device roles 0-2. All other information is the same.
Examining the start of each of the drives shows that there is data there.
head -c=128 disk1_data
XFSB nÙp
†/@@––Ny»Rû“û ° 0 € =„
head -c=128 disk2_data
INAÿ ¯A—zö:»´ FùÓ@àQqas0„P ^ ÿÿÿÿ 0share @spool
head -c=128 disk3_data
ÿØÿà JFIF e e ÿþ Created by AccuSoft Corp. ÿÃ ÿÄ #
ÿÚ ÿ à _æŒå9±Ü‡”î³¹v
From what I have read elsewhere, this is what I expect if the file system is XFS and the data is in raid5. disk1 has the start of the file system, disk2 starts at an inode and disk3 has data. disk4 is not present, but would contain the checksum of these.
From this stage I have mounted each device onto a loop.
losetup /dev/loop2 disk1_data
losetup /dev/loop3 disk2_data
losetup /dev/loop4 disk3_data
At this stage, mdadm is able to assemble the devices.
mdadm --assemble --scan
/dev/md0 has been started with 3 drives (out of 4)
And running --detail provides the following good news:
Version : 1.2
Creation Time : Tue Sep 8 08:59:06 2015
Raid Level : raid5
Array Size : 1169515008 (1115.34 GiB 1197.58 GB)
Used Dev Size : 389838336 (371.78 GiB 399.19 GB)
Raid Devices : 4
Total Devices : 3
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Tue Sep 8 09:40:17 2015
State : active, degraded
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 512K
Name : it:0 (local to host it)
UUID : deb4c6d2:c2fc193c:a9599de3:a25d0d2c
Events : 8
Number Major Minor RaidDevice State
0 7 2 0 active sync /dev/loop2
1 7 3 1 active sync /dev/loop3
2 7 4 2 active sync /dev/loop4
6 0 0 6 removed
cat /proc/mdstat yields the following
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 loop2[0] loop4[2] loop3[1]
1169515008 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [UUU_]
bitmap: 2/3 pages [8KB], 65536KB chunk
unused devices: <none>
However, when I try and mount the newly created /dev/md0, I always get errors relating to superblocks, magic numbers etc.
fdisk -l /dev/md0
Disk /dev/md0: 1197.6 GB, 1197583368192 bytes
2 heads, 4 sectors/track, 292378752 cylinders, total 2339030016 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1572864 bytes
Disk identifier: 0x00000000
xfs_check does not seem to like the file system
xfs_check: /dev/md0 is not a valid XFS filesystem (unexpected SB magic number 0x00000000)
xfs_check: WARNING - filesystem uses v1 dirs,limited functionality provided.
xfs_check: read failed: Invalid argument
cache_node_purge: refcount was 1, not zero (node=0x9dd5930)
xfs_check: cannot read root inode (22)
I have run xfs_repair and it ran all through the night just outputting ............. to the screen, unable to find any secondary superblocks.
And this is where I am a bit stuck.
Any advice is greatly welcomed.
Best wishes
Ben
dd if=/mnt/sdd3 of=/share/disk1_data
which doesn't make much sense, and you seem to be using/dev/md/0
and/dev/md0
interchangably throughout. This makes it hard to see exactly what happens. Also, RAID 5 uses distributed parity, and as such does not have a dedicated parity disk; the effect in practice remains the same though: the ability to survive the loss of any one disk, no more.dd if=/dev/sdd3 of=/share/disk1_data
, this was taken from the notes of the person who tried this recovery the first time. Discrepency betweenmd/0
andmd0
has also been fixed. Other than that, I believe everthing is correct.