1

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

2
  • You seem to be confusing disks, partitions and file systems. Could you please go over your question again, and verify that each example command and output is accurate? For example, near the top you do 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.
    – user
    Sep 8, 2015 at 11:39
  • I think the command I meant a the top is 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 between md/0 and md0 has also been fixed. Other than that, I believe everthing is correct. Sep 8, 2015 at 12:56

0

You must log in to answer this question.

Browse other questions tagged .