0

I'm sorry if the title is misleading however I did not know how to ask the question in a better way.

At work I had to install windows on a machine that had debian. I has three partitions one for root, one for home and one for swap. In order to make space for windows I wanted to reduce the size of the partition for home (from 950 Gb to about 650 Gb where only 150 Gb were occupied). I had done this a bunch of times before and did not have any problems (was using a GParted Live CD). However the resizing got stuck and after an hour (it had never taken more than maybe 15 minutes in any other machines with the same sizes) I stopped the process.

Needless to say Debian booted and could not mount the home (which is understandable). I ran the command fsck -y /dev/sda6 (as asked by the OS) and it stayed for good long while saying that there were multiple references to inodes and wheather I wanted to clone them (the -y option was to say yes to all). Each of these question was for a specific file (I could see the indivual names for pdfs, codes and such) in the machine. After it was done, I rebooted the system, Debian started perfectly, however there was no data in the home. I thought that It was attempting to recover the data. I was clearly wrong.

Can any one tell me what happened? Are all the files lost? If so, what where all those question about cloning the data??

2
  • Is there anything in /home/lost+found?
    – MadHatter
    Mar 17, 2015 at 11:33
  • Yes!! It was full of folders and files with name format #HUGE_NUMBER which I suspect was the INODE number. There might still yet be something salvagable. Thank you.
    – aarelovich
    Mar 17, 2015 at 11:57

1 Answer 1

0

Firstly, in aborting a file system shrinking half-way through you have probably unrecoverably roached the file system; that is, you won't get it back as it was.

Secondly, the fsck seems to have reconnected a bunch of valid-but-disconnected inodes under /home/lost+found, and you're going to go through this directory hoping to find important files.

The lessons to learn from this are firstly, to fsck a file system before resizing it, especially if shrinking it. Secondly, not to interrupt a FS resize. And thirdly, your backup strategy is unfit-for-purpose, and needs a major overhaul.

1
  • The reason I stopped the resizing was becacuase the processed had hang. No cpu nor HDD usage. I've never talked a backup strategy because there was none. Otherwise I would not have bothered to ask the question. Thank you anyways.
    – aarelovich
    Mar 18, 2015 at 15:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .