Catastrophic data loss event
Posted: 10 Oct 2019, 19:36
I recently set up an Intel NUC8i7BEH using ZFS root on Linux Mint 19.2 Cinnamon 64-bit, to replace the ancient 10+ year old Toshiba laptop that I had been using. After I had copied all my data over everything was fine on my new setup for months. One fateful day around this September 16th or so, at about 11 AM in the morning, I made a mistake : I had a drive with a huge amount of very important data on it and I was trying to figure out why the rsync backup script that I had written wasn't working correctly when backing up the data to another ZFS backup drive. I saw that the problem was with the wine directory, so I just blindly, without thinking, issued a "sudo rm -rf wine". Unfortunately, it turns out that the "wine/dosdevices/z:" directory was a link to my root directory! >:( After I had realized what had happened I panicked and did all the wrong things. I issued an ALT-SYSRQ-RSEIUNB. I then booted off of a recovery USB drive and rolled back my ZFS datasets to around 10 AM that morning and restored my system. I then went to check, over the course of three or four mounts and umounts ( oops! ), if the ext4 formatted external drive that I was trying to backup and which had been mounted in my "media" directory was intact. Well, it wasn't
I'd say about 50% of the files had been deleted. I ended up using ext4magic to attempt a restore, but, I never got any more data restored that wasn't already in the partial backup. Note to self : if something like this happens again, *immediately* unplug drive, *don't* mount it again and then save the journal. Anyways, today, I recovered a huge amount of files from a dd image of the drive using photorec. The drive contained many old Windows and Linux system backups, disk images, journal notes, ideas, source code and my other irreplaceable items. What I really want to recover are all the ASCII text files which consist of my source code, journal entries, ideas etc. I'm hitting myself for not prefixing the contents of these types of files with some type of signature. As it is now, I have recovered about 100K+ ASCII text files, with seemingly random names. I first plan on removing any duplicates. But, I was wondering if there's any tool out there that can parse the text files and determine if each file is some configuration cruft that I don't need or is actually something that I want and is important. My guess is that without strong human-level AI, I'm going to have to do it manually :/
Since the data loss event, I'm hesitant to use "sudo rm -rf" anymore. Also, the man page for rm says :
Shouldn't this have prevented rm from bulldozing through my filesystems?
Any suggestions or help would be appreciated.
Thanks,
jdb2
I'd say about 50% of the files had been deleted. I ended up using ext4magic to attempt a restore, but, I never got any more data restored that wasn't already in the partial backup. Note to self : if something like this happens again, *immediately* unplug drive, *don't* mount it again and then save the journal. Anyways, today, I recovered a huge amount of files from a dd image of the drive using photorec. The drive contained many old Windows and Linux system backups, disk images, journal notes, ideas, source code and my other irreplaceable items. What I really want to recover are all the ASCII text files which consist of my source code, journal entries, ideas etc. I'm hitting myself for not prefixing the contents of these types of files with some type of signature. As it is now, I have recovered about 100K+ ASCII text files, with seemingly random names. I first plan on removing any duplicates. But, I was wondering if there's any tool out there that can parse the text files and determine if each file is some configuration cruft that I don't need or is actually something that I want and is important. My guess is that without strong human-level AI, I'm going to have to do it manually :/
Since the data loss event, I'm hesitant to use "sudo rm -rf" anymore. Also, the man page for rm says :
Code: Select all
‘--preserve-root’
Fail upon any attempt to remove the root directory, ‘/’, when used
with the ‘--recursive’ option. This is the default behavior.
Any suggestions or help would be appreciated.
Thanks,
jdb2