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 loop4 loop3 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.