From owner-freebsd-fs@FreeBSD.ORG Tue May 24 18:43:01 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CD5816A41C for ; Tue, 24 May 2005 18:43:01 +0000 (GMT) (envelope-from bv@bilver.wjv.com) Received: from wjv.com (fl-65-40-24-38.sta.sprint-hsd.net [65.40.24.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF27C43D4C for ; Tue, 24 May 2005 18:43:00 +0000 (GMT) (envelope-from bv@bilver.wjv.com) Received: from bilver.wjv.com (localhost.wjv.com [127.0.0.1]) by wjv.com (8.12.11/8.13.1) with ESMTP id j4OIgvk8085290; Tue, 24 May 2005 14:42:58 -0400 (EDT) (envelope-from bv@bilver.wjv.com) Received: (from bv@localhost) by bilver.wjv.com (8.12.11/8.13.1/Submit) id j4OIgvGY085289; Tue, 24 May 2005 14:42:57 -0400 (EDT) (envelope-from bv) Date: Tue, 24 May 2005 14:42:57 -0400 From: Bill Vermillion To: Paul Mather Message-ID: <20050524184257.GB84311@wjv.com> References: <1116955638.48224.27.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1116955638.48224.27.camel@zappa.Chelsea-Ct.Org> Organization: W.J.Vermillion / Orlando - Winter Park ReplyTo: bv@wjv.com User-Agent: Mutt/1.5.6i X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on bilver.wjv.com Cc: freebsd-fs@freebsd.org Subject: Re: Recovering UFS2 content via Sleuthkit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bv@wjv.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 18:43:01 -0000 While humming that old rock song Yackety Yacc - Dont Awk Back Paul Mather sang or SED something like this: > Has anyone managed successfully to recover deleted file content > using, say, Sleuthkit, or is deleted UFS2 content recovery > not feasible (aside from sifting manually with a disk sector > editor)? I've not used Sleuthkit but I've managed to recover files using TCT - The Coroners Tookkit and the program 'lasarus' in conjunction with 'unrm'. > I tried Sleuthkit from the ports collection, and although I can > find deleted content using it, it's not possible to recover > that content because too much important information has been > lost from the inode: specifically, although information like > the owner and timestamp information appears to be preserved, > vital data such as the size, direct blocks, etc. are all zeroed, > rendering the deleted content unreachable (or, rather, reducing > the problem back to a manual search). > So, am I right in thinking that even if the inodes and blocks > belonging to a deleted file have not yet been reallocated or > used again, it's still not feasible to recover the deleted > content easily because of the data loss inflicted upon the > deleted file's inode(s)? In other words, that the only data > recovery possible is via manual means (searching for signatures > and trying to piece together fragments)? 'lazarus' has options to build files or build an html structure. 'unrm' is preferable to use over 'dd' because you use it to search the disk only for unallocated blocks. What you will often find in the recovered files are parts of two files at times, or only part of one large file. This is because the 'unrm' goes block by block through the drive, and files are not neccesarily contiguous. When I ran 'unrm' and 'lazarus' after stupidly not checking a command line [I accidentally remove files like this about every 6 or 8 years :-( ] I saved the output of the unrm to another partition, then ran lazarus to parse those pieces found by 'unrm'. Then when I got the whole segment done, I just moved that entire tree into my XP machine and used the 'search' utility to look for strings. My problem was that I didn't notice the missing files for about a week and I do run a news machine so I dinged a lot of files. Nothing is easy when it comes to recovering lost files. But you learn more about the system, and more importantly it reinforces your checking to keep from doing this again - hopefully. > Also, I wonder why some, but not all, information is scrubbed when a > file becomes deleted (especially information in the inode). Probably for performance problems. There has been talk about buildding an FS that will zero blocks when you remove the indoes, and in that case you will never recover anything. An 'rm' just essentially frees up the inodes, and doesn't do a thing with the on-disk blocks. > PS: Please Cc: me on replies, as I'm not subscribed to this list. Done. Best of luck on your attempts. 'tis painful and I've done it. If you run lazarus to output html you may be surprised to find what else lurrks on your disk that you thought you had gotten rid of. Bill > "Without music to decorate it, time is just a bunch of boring production > deadlines or dates by which bills must be paid." > --- Frank Vincent Zappa I'll go along with those sediments too. Bill -- Bill Vermillion - bv @ wjv . com