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??

  • Is there anything in /home/lost+found? – MadHatter Mar 17 '15 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 '15 at 11:57
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.

  • 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 '15 at 15:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.