Re: Partition problems.
Thanks for your reaction. The NAS in question is a QNAP TS-109, a one bay
model. From what I could gather the firmware is stored in flash and the disk
is used to it's maximum for data storage. This is the layout I see when
doing "cat /proc/partitions":
The guys from Qnap have connected to the system in the past to try and
repair it and they claimed the data was there but the "system partition is
I'm letting ddrescue do its thing again, hopefully getting a better image. I
found some things online in the Forensics wiki:
ddrescue --no-split /dev/sdb image log
ddrescue --direct --max-retries=3 /dev/sdb image log
ddrescue --direct --retrim --max-retries=3 /dev/sdb image log
Once the process completes I'll let e2fsck run again and come back with
detailed error messages. Fingers crossed.
Sent: Friday, November 04, 2011 6:17 PM
Subject: Re: Partition problems.
On Thu, 03 Nov 2011 15:48:50 +0100, Johan Verbelen wrote:
I've been trying to fix this disk for a week now, but everythin I tried
hasn't been working. I'm a linux starter however, so that doesn't help.
The drive in question is a 120G Maxtor that was housed in a NAS. After a
power outage the NAS reported the disk as empty. I took it out and
assumed a hardware error. I have access to a harddisk hardware test
suite but all those tests indicated that the disk is fine. The NAS runs
an embedded linux (debian based) and has ext3 partitions so I started
looking around for possible solutions.
What kind of NAS appliance was that and what kind of disk layout did you
Maybe what hapenned is that hard disk was part of a RAID or spanned
volume and after the power outage the disk itslef was healthy but the
RAID volume was put in degraded mode or the spanned layout had any
Using ddrescue an image was made, it reported 10 errors (45056B). I
took a 1TB drive and installed that in my Ubuntu 32 bit machine as
secondary disk with two partitions. One holding the image, one to hold
the extracted image. When running e2fsck on that extracted image it
reports a bad magic number in a superblock. I tried other superblocks
and the last one worked (102400000), however, the system ran out of
memory trying to fix errors (4Gb system memory). I decided to run
Ubuntu 64 bit live cd and hope that would solve the memory issue, but
the issue remained. I then booted my main machine (12Gb memory) with
Ubuntu live 64bit, but alas, out of memory again.
The exact error message could have been useful. It could have been that
"e2fsck" was complaining about "/tmp" or tmpfs space or something that
can be tweaked easily... Of course, a LiveCD environment is very limited
to carry out these recovery tasks because the live system has limited
room for doing anything :-)
At this point my hair is turning grey and I'm seeing linux commands in
my sleep (good, I'm learning!). I decide to try some datacarving.
Foremost and Photorec worked but the amount of usable files was pretty
low and a lot didn't show up. At an end, I ran Testdisk and Parted.
Both detect partitions but seem to think they're ext2. After they do
their thing I still can't access it though (possibly I'm doing
something wrong, this was late last night). Does anyone know how to fix
the issue or what I could try next?Thanks for any advice you can
dispense. :) J.
If the device was acting as a single hard disk or volume, Photorec is one
of the recommended tools for data recovery, so if you had no success with
this tool it does not look good :-(
If the disk was part of any kind of RAID 0, LVM or spanning layout maybe
the remainder data is needed in order to be able to perform a full
recovery, I would contact the manufacturer of the NAS and ask for any
advice on how to proceed in such cases.
((I'm sorry if this is a double post, I tried using a different e-mail
address yesterday but since it didn't show I assumed it might have
Mmm, this is the only post I have seen from you but AFAIK there is no
filter in this mailing list.
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact