3

As I was resizing my partitions using GParted, my laptop battery ran out, and the process was interrupted.

Now, I am unable to mount the partition which I was trying to resize. I get the following error when I click to mount the partition on nautilus:

Error mounting:
mount: wrong fs type, bad option, bad superblock on /dev/sda3,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

How can I go about recovering my data? Is there a safe way to attempt to force-mount the partition in question? Any help towards recovering my data is sincerely appreciated.

Gilles 'SO- stop being evil'
  • 60,593
erjoalgo
  • 1,041
  • Please do share your syslog – Farid Nov 18 '12 at 13:56
  • 1
    This won't help you now, but it is not a good idea to partition discs while on battery power. Also for the future make a backup of all important data before trying anything risky (installing or upgrading an operating system, resizing or moving partitions, ...). – To Do Nov 18 '12 at 14:10
  • Thanks. That is not quite a duplicate, since my partition was ext4, not NTFS, and I did not delete the partition, but was in the process of moving it when my laptop shut off. What do you mean syslog? This happened a while ago, while I was using GParted from a CD. I have been using Ubuntu on the same drive, but on a smaller partition. The rest of the drive has remained intact. – erjoalgo Nov 20 '12 at 23:52
  • @ToDo The charger plug accidentally slipped off the laptop, and rather than giving me dire warnings, Ubuntu only remained silent. – erjoalgo Apr 19 '13 at 08:41

2 Answers2

3

Some months ago, @psusi said: "Your data is pretty much toast. At this point you need to restore from backup..."

I didn't believe it. My computer has only about 4GB of RAM, and the partition being moved was around 350GB. If we assume that the "move partition" operation of GParted is correct, 4GB should be a limit on the amount of data that could have been lost. (Otherwise, the "move partition" operation likely could not complete without loss of data).

Indeed, I was able to recover my directory tree, albeit a bit shuffled (since the move operation had been interrupted, a strange directory configuration resulted, where about half of my home directory was inside one folder).

The answer was testdisk, which was able to detect the filesystem in question. After this was detected, I copied the files onto an external HD. This learning experience has brought me closer to enlightenment via http://www.taobackup.com/.

erjoalgo
  • 1,041
0

Your data is pretty much toast. At this point you need to restore from backup. If you don't have backups, let this be a lesson to you to start making them. If there are still files you want to attempt to recover, pray, and try the photorec utility from the testdisk package.

psusi
  • 37,551
  • @user84207, I just noticed you said resize, but I was thinking you said move before. In that case of move, then there is no way to recover the filesystem since there is no way to tell how much got moved before the crash. If this is an ext4 filesystem and you were only resizing it, and not moving, then I believe e2fsck can recover it. – psusi Nov 19 '12 at 18:37
  • Yeah, I was moving it. I think what I said still applies though. I mean, the data physically is still there, I only need a way to access it in the correct way. Perhaps I might need to study the ext4 specification and the GParted move algorithm. What I mean that it should definitely be possible to recover my data. – erjoalgo Nov 20 '12 at 23:49