Date: Thu, 28 Feb 2013 01:24:40 -0800 From: Doug Hardie <bc979@lafn.org> To: Polytropon <freebsd@edvax.de> Cc: "Questions @ FreeBSD" <questions@freebsd.org> Subject: Re: Fat Fingered An 'rm -rf' of Important Files Message-ID: <72390541-398C-4E16-A033-80076D1079BD@lafn.org> In-Reply-To: <20130228100211.17e2cb43.freebsd@edvax.de> References: <512ECA4A.3030202@gmail.com> <20130228100211.17e2cb43.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28 February 2013, at 01:02, Polytropon <freebsd@edvax.de> wrote: > On Wed, 27 Feb 2013 21:08:58 -0600, Joseph A. Nagy, Jr wrote: >> Okay, I know I should pay more attention to what I'm doing, and = having=20 >> separate partitions isn't an excuse for regular backups. If we can = skip=20 >> the finger wagging on that part I'd appreciate it. >=20 > I've experienced similar and different "moments of unintended > successful rm", so I won't mention missing backups. ;-) >=20 >=20 >=20 >> Is there any way to retrieve any of them? >=20 > Yes, but it's not easy. Prepare to go on a journey though > file system documentation, trial & error. >=20 > Obviously we're talking about a USB stick, so no TB amount > of data has to be processed. First of all: Do _not_ alter > the USB stick in any way. No matter what you do, it can > always get worse. >=20 >=20 >=20 >> I've not wrote any data to=20 >> either partition since the accidental deletion. >=20 > Very good. >=20 > You can first make a copy of the file system (the whole > stick) and use that: It will be faster to access and if > you do something wrong, the original data (which we can > assume is still there) won't be affected: >=20 > # dd if=3D/dev/da0 of=3Dstick.dd >=20 > Now let me introduce you to the "list of helpful programs > in case you've done something ultimately stupid" which I > have already repeated several times on this mailing list. > I'm sure you can find some program that will help you. > See my individual notes regarding your specific situation. >=20 > I will "refactor" text from a previous message. >=20 > A worst-case tool to recover data (not file names, but file > content) is testdisk; in ports: sysutils/testdisk. It's also > on some diagnostics and recovery CDs like UBCD. >=20 > You can also try this: >=20 > # fetch -rR <device> >=20 > Also recoverdisk could be useful. >=20 > The ports collection contains further programs that might be > worth investigating; just in case they haven't been mentioned > yet: >=20 > ddrescue > dd_rescue <- use this to make an image of the stick! > magicrescue > testdisk <- restores content > recoverjpeg > foremost > photorec >=20 > Then also >=20 > ffs2recov > scan_ffs >=20 > should be mentioned. >=20 > And finally, the "cure to everything" is found in The Sleuth Kit > (in ports: tsk): >=20 > fls > dls > ils > autopsy >=20 > Keep in mind: Read the manpages before using the programs. It's > very important to do so. You need to know what you're dealing > with, or you'll probably fail. There is no magical tetroplyrodon > to click ^Z and get everything back. :-) >=20 > Proprietary (and expensive) tools like "R-Studio" or "UFS Explorer" > can still be considered worth a try. Their trial versions are for > free. "UFS Explorer" even works using wine (I've tried it). >=20 > Note: >=20 > I've dealt with a comparable problem some months ago when > a "Windows" PC has "repaired" a FAT file system on a USB > stick, with the "excellent" result of all data being gone. > I could restore everything except the original file names > (which I wrote a script to "conclude" them from file metadata > and content). >=20 > So it should be possible. I see this issue way too often. The above information should be put in = the Handbook. It would be nice to have it fleshed out more, but if = nothing else, the above would be helpful to others who run into similar = issues.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?72390541-398C-4E16-A033-80076D1079BD>