Crash and Consequences
by
, 30-09-2011 at 03:55 PM (9198 Views)
As some with reporter/staff privileges may have noticed, Spam was rife in the last few days - and for once I have a good reason to not have logged on in the past few days...
Bar the history, the problem I faced at the start of the week was an entirely re-written inode structure on my home ext4 partition - linux users among us will note this as serious.
To make matters worse, this occurred while I was testing out direct access to the disc in an attempt to manipulate Ext for moving data more efficiently; it worked at 40Mib/S which for my hard drive is decent and more than what GParted can offer by an ample margin... But in my true spirit, I was working on data live (no backup) and of course, I failed to note the location of the partitions' start and end sectors. Move completed, some inodes didn't match and boom.
Later due to my inadvertence while in the notorious 'sudo su' shell I made a badly flagged mke2fs over my partition .
At the time, I knew my superblock had been overwritten and I had 1.8million possible sectors to try so I had a brainwave in the little line as follows:
and to sew it back together is just a quick:Code:sudo dd if=/dev/sda bs=2048 conv=noerr,sync | pv | gzip -c -1 | split -b 2048m - /media/backupdsk/backup.gz-
Now why split it into 2gb blocks? Because I had some data I could not wipe on my drive, formatted as NTFS. I do not know if this normal linux behaviour but after 16 hours I noted that large (280GB+) files on an NTFS disk slow down, exponentially... PV is there because I like being nosy and having stats to look at - especially when/if it hangs...Code:cat /media/backupdsk/backup.gz-* | pv | /media/finaldestination/Patchwork.gz
The result: a disk image to cat ad grep for data I need, and a move to mint from the scares of ubuntu oneric and natty... Eventful no? Moral of the story: don't mess with your FS, and if you do: BACK IT UP!