Sign in with
Sign up | Sign in
Your question
Solved

Lacie 2big Network failed. how to recover data

Last response: in Storage
Share
October 16, 2009 2:11:08 PM

Hello, I'm a first time poster. First real problem I suppose.

My 1 Terabyte Lacie 2Big Network drive failed. It was configured in SAFE (Raid 1) mode.

When powered up the front and rear LEDs turn on, but the drive will not appear on the network; it does not appear on my router's client list, its admin page is inaccessible and pings get no response. The drives inside seem to turn, I not sure of the fan though (seems not).

I have tried several suggestions which I found on the web. Mostly ther are related with power supply failures.
Lacie tech assistance, by my description, also suggested it might be a power supply problem.
I live in Argentina and Lacie won't ship a power supply out here.

Here's what I've tried.
1) Powered the Lacie 2Big from a PC power supply. (Only one drive inside to protect the data on the other)
2) Powered one of the Seagate drives inside from the PC supply and the NAS circuitry from the Lacie supply.
3) Mounted one of the Seagate drives fron the 2Big into a PC and used Explore2fs and Disk Internals linux Reader to get the data off of it.

none of these approaches worked, but Linux Reader is the closest I've come to my data. Thing is the Drive seems to not have my data on it. All I see is Linux partitions and file structure but not my data. I'm not experienced with linux, but I've combed and searched the directories with no luck.

Could the data be encrypted or hidden? The drive had user passwords.
So far I have done the above tests with only one drive mounted because I don't want to jeopardize the other; Will the NAS work with only one drive in it in Raid 1 Mirror Safe mode?

Any suggestions on how to proceed?

Thanks , Christian.

Best solution

a b G Storage
October 19, 2009 1:09:53 PM

Welcome to the forums!

You can take the remaining drive out of RAID1 and use it alone or you can rebuild the array with a new drive.
See your manual for instructions on how to rebuild the array.
Share
October 19, 2009 3:38:40 PM

Thank you for your reply.
I am unable to rebuild the array because the actual Lacie casing is what is not working. The individual hard drives are, apparently working properly.
I am therefore trying to mount one of the two drives into a PC and retrieve the data but I can not locate my data.

My question regarding this issue is whether the data is hidden or encrypted by the Lacie firmware.

Thanks again.
m
0
l
Related resources
a b G Storage
October 19, 2009 4:00:35 PM

Sorry. Probably not encrypted. Find out what the partition type is with GParted LiveCD. Try reading the data with a Ubuntu LiveCD.
Tell us the partition type, like ext3, reiserfs, etc.

m
0
l
October 24, 2009 5:23:24 PM

I have the same issue with the same drive. I am trying to access it through Linux, and can see nothing but Linux files and folders. Evongugg suggested taking the drive out of RAID1 to use it alone. Can someone explain how to do this? I am using Ububtu installed on VMWare Fusion on my Mac. Also, how would I know the Partition type?
m
0
l
a c 127 G Storage
October 24, 2009 5:29:07 PM

Please give us the partition layout of the device, a screenshot of Gparted (Partition Editor in System -> Administration) or the output of an "fdisk -l /dev/sdX" command, where /dev/sdX is the name of the detected harddrive, for example /dev/sda or /dev/sdb.
m
0
l
October 24, 2009 6:36:46 PM

I think I typed something wrong - please advise:


jason@jason-ubuntu:~$ fdisk -1 /dev/sdb
fdisk: invalid option -- '1'

Usage: fdisk [-b SSZ] [-u] DISK Change partition table
fdisk -l [-b SSZ] [-u] DISK List partition table(s)
fdisk -s PARTITION Give partition size(s) in blocks
fdisk -v Give fdisk version
Here DISK is something like /dev/hdb or /dev/sda
and PARTITION is something like /dev/hda7
-u: give Start and End in sector (instead of cylinder) units
-b 2048: (for certain MO disks) use 2048-byte sectors
jason@jason-ubuntu:~$
m
0
l
October 24, 2009 7:17:17 PM

m
0
l
May 28, 2010 1:50:01 PM

I had a similar issue running Raid 1 on a Galaxy MGB (piece of junk) which died. The drives were OK though. When i took the drives out and placed them in my PC I could see them in device manager but they weren't visible in my computer. I searched the web for anyone who had a similar problem and didn't find much but i did find this site and thought i would share my experience in hope it may help someone. I'm not a tech whiz and know nothing about linux so i was willing to pay for a solution. I ended up finding and using a program called UFS Explorer version 3 ( http://ufsexplorer.com/download.php ) . It gave me access to all of my files and allowed me to copy and paste all the data. For the headaches it saved me i thought it was very reasonably priced.
m
0
l
April 13, 2013 2:29:34 PM

evongugg said:
Sorry. Probably not encrypted. Find out what the partition type is with GParted LiveCD. Try reading the data with a Ubuntu LiveCD.
Tell us the partition type, like ext3, reiserfs, etc.



OK. after having spent some time today at a customer's site to try and recover the data off his failed Lacie 2big Network (version 1) 2x500GB RAID1, I know a few answers to that one, and I'll put them here in case somebody else is in need of this info. It seemed pretty clear that it was the enclosure and not the drives that had failed. The Lacie drive did not boot up, front light all red, and rear LED's one solid blue, one blinking blue. (I.e. a case that is nowhere mentioned in Lacie's docs.)

I stuck one of the two Lacie hard disks into the customer's OS-X Snow Leopard (10.6) box. It reported that it couldn't recognise the disk and I would have to format it first. No way! But it did see the disk itself and had assigned device files to its partitions: /dev/disk1s2 was just under 500GB, and disk1s5 through /dev/disk1s10 were smaller partitions of between 8 and 600 MB. Some of these were recognised as filesystem type EXT3 (i.e., a Linux-type file system).

Next, I tried to copy the disk partitions byte by byte onto an external 1TB USB drive I had brought along, but this wouldn't work because out of the box the Snow Leopard could not write to the external NTFS-formatted drive (and I was not going to give up the other data on that drive and reformat it!). So, I installed a version of NTFS for the Mac that I found on Seagate's website, and after a reboot I could not only write to my USB drive, but, hurrah, two of the partitions on the original drive from the Lacie array had been mounted. So, apparently, the ability to mount EXT3-filesystems has sort-of come as a bonus with the NTFS package. Go figure!
Looking into the, now mounted, partitions of the Lacie drive, I could see that they obviously contained a Unix-like operating system.

At this point, I started copying the raw partitions onto my external drive, using "dd" from the command line, but gave up after about 20GB of the mammoth 500GB partition had been copied. Nevertheless, the command "file *" on these copied partitions told me that not only some of them were EXT3, and one of them a Unix/Linux swap file, but that the monster partition was something called "CGI XFS". That's a journalling filesystem once developed by Silicon Graphics and used on their Irix range of Unix boxes.

Now, it turned out that there is some software out there in cyberland to mount XFS under MacOS X, albeit read-only (which was, of course, all I wanted!). The blurb said that it needed OSX 10.7, but I installed it anyway, and then tried, again from the command line, the magic incantations of:

$ sudo su
Password: <an administrator's password here>
# mkdir /Volumes/fuse
# fuse_xfs /dev/disk1s2 /Volumes/fuse

only to get an error message that "fuse_xfs" could not find a needed shared library called something like /usr/local/lib/libosxfuse.i64.2.... In desperation, I symb-linked the most promising looking similarly named file within /usr/local/lib to the requested name, and - bingo - the filesystem mounted and I could see my customer's files. Phew!

Note, however, that for some reason unknown to me, the mounted filesystem did not appear in the finder, nor could even the mount-point /Volumes/fuse be seen by any user other than root. No idea why, but I wasn't going to argue about that with a "fuse-xfs" that was described as "alpha software". I simply used cp -r from the command line to copy across the filesystem contents to the USB drive. This copy is still running as I am writing, and the jury is out whether the resource fork will be there or what else may be wrong (some of the backups on the Lacie drive were for an OS-9 machine!). It could well be that only Lacie's own software might ultimately be able to re-assemble a proper Mac-like file from the bits of Unix that it actually stores on its hard drives. But if your system is pure OS-X, you'll probably be OK.

Good luck to all,

Martin
m
1
l
May 5, 2013 2:39:29 PM

Following up on my own post from a few weeks ago:

The story only really began there!

Yes, the copy operation described transferred all the stuff from the LaCie drive to my USB drive - about 200 GB of actual files. If my customer had been running a Windows or a Linux shop, that would have been that. But, as mentioned before, he is an Apple guy, and runs not only Mac OS X, where the raw files are on the whole good enough and usable, but he actually has ancient MacOS-9 machines, with all the idiosyncrasies that Apple's unrecognised geniuses under the guidance of their recognised genius Steve "One-Button-Only" Jobs built into their OS in the 1980s.

OS-9 files have Resource Forks (which is where OS-9 and earlier squirrel away things like the actual code of executable programs, as well as information such as icon shapes and which application to launch when double-clicking on a file) and so-called "Finder Information" (which is another place where the system stores file type - even Mac OS X uses this one!).

When transmitting such a complex Macintosh file structure over the network to another computer, or to network-attached storage, this is done by encapsulating all the additional information, plus the file data content itself, as a bit stream in a format called "AppleSingle". Alternatively, it can be sent with the data in one file, and all the other bits in a separate "companion" file - this way of doing it is called "AppleDouble format". All this is explained in RFC-1740, a document of as ancient a vintage as 1993.

LaCie uses the AppleDouble format to store Apple files on its file system, which, being a Unix file system, is "single forked," i.e. a stream of bytes with no "resource fork" anywhere in sight and only Unix meta-information, which is far less than the "Finder Info" that Apple needs. What LaCie does, is store the data file, the first half of the AppleDouble format, perfectly normally in the usual directory structure, and the companion file in a subdirectory to each directory, called ".AppleDouble/" (note the dot). Just for good measure, LaCie adds additional information about its own file layout in the AppleDouble file, but all strictly to the letter and to the bit according to RFC-1740.

MacOS X, meanwhile, has developed its own facilities to split off resource forks (the command "SplitForks" - see "man SplitForks" from a terminal window), and the service command "/System/Library/CoreServices/FixupResourceForks" to recombine the parts - see "man FixupResourceForks". But instead of putting the split-off AppleDouble-formatted companion file into a subdirectory, SplitForks puts it into the same directory, with an additional ._ in front of the filename! And FixupResourceForks expects it there.

It would seem obvious what to do next: take each of LaCie's .AppleDouble/X and rename it ._X, and then run FixupResourceForks on the directory. (By the way, the directory itself has a companion file called .AppleDouble/.Parent, which would have to be renamed to "._." [watch where those quotation marks are].) But it's not that easy!

In their wisdom, Apple's engineers, who never really believe in Open Standards, deviate from RFC-1740: even a perfectly well-formed companion file to X, called ._X, will elicit an error and terminate the FixupResourceForks command if it contains anything else than the entries for the Resource Fork and the Finder Info, with the entry headers in that order, and the associated data in the opposite order. Thus, simply renaming a LaCie .AppleDouble/X to ._X is not good enough!

In the end, I had to write a C-program that parsed the LaCie AppleDouble file and extracted the bits that Apple's FixupResourceForks would accept, and write those bits out to a ._X file before running FixupResourceForks. And since I have no C-compiler on my Mac, this meant transferring those hundred of Gigabytes back and forth between a Linux machine and the Macintosh. Very time consuming, but, in the end, I have an external, HFS+ formatted disk (i,.e. in Apple's format) with all the original files on it, so that even MacOS-9 can read.

I also have a happy customer, if not a happy accountant!

Your mileage may vary!

Martin
m
1
l
!