Terastation Data Recovery
At the forums we face the problem that someone cannot access his Terastation/TerastationPro anymore quite often. Most of the time there is valuable data on it which is really needed to extract again.
This article is all about how you can recover your data. Once you have recovered your data, you almost certainly want to proceed to the next stage of getting your TeraStation back into an operational state. There is a separate article that covers TeraStation Recovery at the hardware level. Often the hardware recovery will also allow you to recover your data without doing the data recovery steps described in this article, but if that level of recovery goes wrong your data is likely to be lost beyond any chance of getting it back. You therefore have to decide how important your data is to you and whether you are prepared to take that risk.
- 1 Why?
- 2 How To
- 3 Some official info from Buffalo on the RAID Configuration
The Terastation/TerastationPro will only show in the webinterface that rebuilding the array is the only option. But there are other options to get the data back.
With RAID5 the data is distributed accross all disks and one disk stores an XOR checksum of the remaining (n-1) disks. So you can loose 1 disk.
In theory you should be able to connect all disks to a workstation, and repair it there. In practice this does not work, as the byte order of a recular workstation (i386) is different and the MD driver is not endian agnostic. An Apple Mac is required for this.
xfs_repair on the Terastation worked for me. See reb's post : Raid 5 '4 red lights' issue
Data Recovery Method With PPC Apple Mac
This part contained some confusing and outdated information so I rewrote it all having just used the information successfully.
It is possible in some cases to recover a Terastation array in situations where the system flashes all four red lights and shows in the web interface that the array is dead and should be recreated, losing all your files. I've done so successfully.
To recover a Terastation array (assuming RAID5 here) you need the following:
- a PPC powered Mac (Mac Mini, iMac, whatever) with at least one USB connector
- External USB disk boxes for your disks. I assume you need 4 as I did. They don't have to be identical. Anything works. Mine were of 3 different brands, there was no change.
- Possibly an USB hub to be able to connect (at least) 5 devices to your system
- Enough USB disks to be able to store all the data you want to recover from the damaged array
- A recent Ubuntu LiveCD for PPC (for example .)
You don't need to erase or change the current operating system on the PPC Mac in any way. After the process it will be exactly as it was, so don't worry.
I'll just assume the reader knows nothing at all about linux, and give the necessary commands. If you know what you're doing you can just figure out what you need from the following.
Download and burn the LiveCD (I hope you know how to do this). Insert it into your PPC Mac, and press down the C key during boot up to have your Mac start up from the CD instead of the hard disk. You should be shown the Grub bootloader window with a nice string of c's on the prompt. Erase them, press enter. The system will start up, and ask for your country and keyboard details. Choose the appropriate values, and watch as the Ubuntu happily recognizes your RAID array and does all the necessary work.
After a while you've got the desktop open. Click on the Applications menu, from there System tools, and Root terminal. Now you've got a beautiful command window in front of you. Now you need to choose whether you want to attempt to back up the files before trying the repair, or just repair the array and hope that's enough.
Backing up the files
root@ubuntu:~# mount /dev/md1 /mnt ro,noatime,norecovery,noalign root@ubuntu:~# tar cjf /media/YOURMEDIA/terastation.tbz2 /mnt/*
If you inserted an USB disk drive in addition to your Terastation array, it will probably be automounted under /media folder under the disk's name. My Lacie 320G USB disk was mounted as LACIE. The commands above assume you want to mount the system in read only mode (does someone want to comment on the parameters? I mounted mine without any but I'm not 100% sure I should've done that. My array is now fine, though.) I also assume the disk you're backing the files up to contains enough space for your Terastation files. I only had 40GB of data there so I was ok.
When done, reboot.
Note: My data partition failed but the OS partition (/mnt/md0) still worked. I had previously enabled telnet access, and was able to get onto the box and used the command
mkdir /tmp/foo mount -o ro,noatime,norecovery,noalign /mnt/md1 /tmp/foo
And was able to remount the partition, edited /etc/samba/smb.conf to point to /tmp/foo and then copy the files off the terastation.
--Thereza 18:42, 31 May 2010 (UTC)
Repairing the Terastation array
This is the hard part. Open up the Root terminal as mentioned above, and type this:
root@ubuntu:~# xfs_repair /dev/md1
..and wait. That's it. Note: You can't repair a mounted drive, so you need to reboot after the data backup done above, or just skip that part. If you do so, I won't be held accountable for a single lost file.
If you want to see some information about your RAID array use this:
root@ubuntu:~# mdadm -E /dev/md1
Pay attention to the State. It should show clean,no-errors but I assume it's clean,degraded or something if you're reading this.
Below is some detailed information some people may find interesting or useful. I haven't touched them, but I didn't need any of it to solve my problem with the array. One reason for this was probably that a year or two has passed and the newer Ubuntu LiveCD does much of the required work automatically.
Here's a quick command reference for linux software RAID newbies like myself - these steps will allow you to locate, repair, assemble and mount the arrays for backup/recovery purposes:
jack@jack-laptop:~# sudo -s root@jack-laptop:~# cd /dev/disk/by-uuid root@jack-laptop:/dev/disk/by-uuid# ls 4cada7c0-2343-406a-a900-52c9c0f412f1 897c0d45-19e5-4b7c-b909-fce40d9874c1 549641db-72df-4012-a9a0-fbbca24d1d95 a680d13c-e9de-40a8-91d7-cc04ad7162ef 5efa4f68-93e9-4ed6-aac4-aad67266d9c3 root@jack-laptop:/dev/disk/by-uuid# mdadm --detail 897c0d45-19e5-4b7c-b909-fce40d9874c1 897c0d45-19e5-4b7c-b909-fce40d9874c1: Version : 00.90.03 Creation Time : Sun Oct 31 16:04:26 2004 Raid Level : raid1 Array Size : 385408 (376.44 MiB 394.66 MB) Device Size : 385408 (376.44 MiB 394.66 MB) Raid Devices : 4 Total Devices : 4 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Wed Dec 13 16:37:19 2006 State : clean Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0 UUID : 586fc2de:f33f4915:b21a2ed6:6eacb444 Events : 0.214 Number Major Minor RaidDevice State 0 8 65 0 active sync /dev/sde1 1 8 33 1 active sync /dev/sdc1 2 8 17 2 active sync /dev/sdb1 3 8 49 3 active sync /dev/sdd1
This was good news, the system partition was clean and ready to assemble and mount. But my first concern is my data, because I'm going to blow away the system partition with the help of the how-to . Let's find that RAID 5 data array:
root@jack-laptop:/dev/disk/by-uuid# mdadm -Q 4cada7c0-2343-406a-a900-52c9c0f412f1 4cada7c0-2343-406a-a900-52c9c0f412f1: is not an md array 4cada7c0-2343-406a-a900-52c9c0f412f1: device 0 in 4 device active raid5 /dev/md1. Use mdadm --examine for more detail. mdadm: 4cada7c0-2343-406a-a900-52c9c0f412f1 does not appear to be an md device root@jack-laptop:/dev/disk/by-uuid# mdadm --examine 4cada7c0-2343-406a-a900-52c9c0f412f1 4cada7c0-2343-406a-a900-52c9c0f412f1: Magic : a92b4efc Version : 00.90.00 UUID : 34d10443:9659647f:e215e986:417e4a7a Creation Time : Fri Nov 19 04:03:08 2004 Raid Level : raid5 Device Size : 155589440 (148.38 GiB 159.32 GB) Array Size : 466768320 (445.14 GiB 477.97 GB) Raid Devices : 4 Total Devices : 4 Preferred Minor : 1 Update Time : Wed Dec 13 16:55:43 2006 State : clean Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0 Checksum : 284f8ae8 - correct Events : 0.84 Layout : left-symmetric Chunk Size : 64K Number Major Minor RaidDevice State this 0 8 3 0 active sync 0 0 8 3 0 active sync 1 1 8 35 1 active sync /dev/sdc3 2 2 8 51 2 active sync /dev/sdd3 3 3 8 19 3 active sync /dev/sdb3
My system crashed (Ubuntu runs a little hot on a Powerbook) and I lost the actual output which showed that the array was rebuilding. It took 7 hours to complete. Once done, all I need to do is assemble the array (using the UUID from the output above) and mount it:
root@jack-laptop:/etc/mdadm# mdadm --assemble --scan --uuid 34d10443:9659647f:e215e986:417e4a7a root@jack-laptop:/dev/disk/by-uuid# mount -t xfs /dev/md1 /mnt root@jack-laptop:/dev/disk/by-uuid# cd /mnt root@jack-laptop:/mnt# ls
--Thirdpig 03:41, 14 December 2006 (CET)
--Edited by WizardFusion
I should note that in the Terastation forums, I read reports of users resurrecting their system partitions and having their data partition appear intact- this was NOT the case when I performed the fresh "blast" of the system partition outline here- After updating the Firmware the TS does not respond
Instead, I found that upon booting up the system, my original RAID 5 partition was deleted and creation of new raid array 1 hand begun automatically in spanning mode. Perhaps this could have been averted if I had copied my original fstab.conf file into the /etc folder on the system partition? Too late now. Sure glad I went through the trouble of rebuilding the RAID 5 array and backing up the data! --Thirdpig 01:47, 16 December 2006 (CET)
Data Recovery on x86 (Windows) using UFS Explorer
As with some other readers, I did not have access to a PPC box to recover data from my bricked Raid 5 TeraStation. Looking around on the net for some way to read the XFS Raid from a Windows box, I stumbled upon UFS Explorer which can recover data from Linux partitions and RAID setups on a Windows box.
Initially, the software could see the partitions but failed to recognize the file system on the RAID. I have spent a few days working with them and they have come up with a new version which can now read the data from an TeraStation XFS formated Raid 5 setup.
The initial hardware setup simply involves connecting the four drives to an Windows box. Depending on your hardware setup, uou may need to get an additional IDE card to accomplish this. Once the hardware setup is completed, you can download the trial version of UFS Explorer at the link above and follow these steps.
- Create a virtual raid (my disk order was 1, 3, 2, 4) but it may need adjusting depending on how you connected the disks
- Select Raid 5, Stripe Size 64K and Left-Symetric.
- Once the raid partition is created, right-click and select "Fine File System".
If all works, you should then see the folder structure of the drive. The trial version of the software will let you browse all files and copy files which are <= 64K. The registration for an individual (non business) license is near 50 Euro. Depending on your data, it is more than worth the cost!
--Sebby1234 12:36, 20 March 2007 (CET)
- The step-by-step instruction in "HOW TO: Recover data from Buffalo Terastation"
- RAID level and drives order detection in "HOW TO: Indentify drives order for drives from XFS NAS"
- And for non-technical users "HOW TO: Connect IDE/SATA drives to Windows PC"
These articles give full picture of data recovery process from Windows environment.
--danw 09:30, 12 November 2008 (EET)
With RAID1 the data is duplicated on each disk, so you can lose all but 1 disk and still have your data available. You rarely use more than two disks, as you lose the capacity of all but one disk. The Terastations system partition is a RAID1 with 4 disks. Note: the Terastations can only do RAID1 for data on two drives.
As all the data is available on each disk, you can simply move just one disk to a different system and access it bypassing the RAID layer. This works on i386 or PowerPC.
As the RAID will be ignored, or not even detected, you should not modify anything or a rebuild will be requierd.
Warning: if an XFS partition, or for that matter any journaling FS, was not cleanely shutdown, the journal will be replayed even if you mount the disk read only. What, of cause, is a modification.
With RAID0 the data is split into stripes and the stripes are distributed over all the disks. If you loose one disk, your data is lost.
Like RAID5 the system you connect your disks to, must be able to detect the RAID to allow you to access your data. So again a PowerPC is required, on the other hand does the TeraStation not support RAID0 anyway.
I doubt the Terastations do RAID0... in the interface the options are RAID5, RAID1, and Spanning.
Span / Linear
When you use span or linear the disks are chaines sequentially. So you could attach one disk at a time to any system, dump the partition and chain them together. You will require some huge ammound of storage but the byte order should not matter.
When you use standard mode, the terastation will not use any RAID. You can attache one disk at a time to any system and copy the data.
If you run out of space on the system partition, which is a mirror set (RAID1), you can access the partition as above.
To mount the partition using the UUID of the partition, but need to use Ubuntu Linux.
To find them type...
cd /dev/disk/by-uuid ls -l
This will give you a list of UUIDs currently available. You should be able to see the currently mounted UUIDs from the redirection arrows
To mount the UUID, type the following...
sudo mount -U aaaaa-bbbbb-ccccc-ddddd-eeeee /mnt
This will mount it to the /mnt folder. From here you can do what you need to.
Some official info from Buffalo on the RAID Configuration
Couldn't think of a better place for this stuff, but here is some information I received from Buffalo Support on the RAID information for the TS-TGL Terastation Pro:
1. What is the starting sector of the raid array?
Device Boot Start End Blocks Id System /dev/sda1 63 771119 385528+ 83 Linux /dev/sda2 771120 1044224 136552+ 82 Linux swap /dev/sda3 1044225 312223276 155589526 83 Linux /dev/sda4 312223277 312576704 176714 83 Linux These are DISK1 partition tables. You can see it by using command 'mfdisk -c /dev/sda' the /dev/sda1 is for system files (rootfs) which is RAID1. the /dev/sda3 is data area which is: RAID1,5. others are not RAID.
2. What is the block size?
4096bytes - the file system block; 64KB - the striped RAID stripe size
3. Is there any parity rotation?
Hope this helps someone! --Wastedlife 06:17, 22 January 2007 (CET)