Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Recovering deleted files using only grep

blog.nullspace.io

Post reply on HN
Print view View original

21–30 of 46 posts

Re: Recovering deleted files using only grep

#21

Post by danielweber »

a3_nm wrote: post #17

How could this work? I would expect this method to yield a bunch of matches corresponding to every version of the file that was once saved and continues to live on the disk. Unless you happen to have a string that only existed in the last version or so, but that's hard to come by... I once did recovery of this kind for a friend (using, I think, photorec or extundelete, not grep) and the hardest part by far was piecin…

I don't think there are any guarantees here, but if he kept on saving the same file with the same name, it probably overwrote the same sector on disk.

Re: Recovering deleted files using only grep

#22

Post by danielweber »

natch wrote: post #8
lelf wrote: post #7

I'm wondering a lot why it's 2014 and https://gist.github.com/llelf/7862414 (it's hammerfs on DragonflyBSD) is WOW (and not some ordinary boring thing everyone use)

parse error

I think he's saying "how come it's now 2014 and everyone doesn't use yet?"

Re: Recovering deleted files using only grep

#23

Post by snori74 »

madaxe_again wrote: post #11

Yeah, been there, done that, although my first step is to umount and dd onto another volume so the sectors don't get reallocated and obliterate the data - and that's generally a sane first step for ANY recovery of this ilk. You haven't lived until you unwittingly run rm -rf on a nfs mount of / on a remote box. Which happens to be the fileserver for a trading shop. In the middle of trading hours.

Indeed. The whole "never run rm -rf" thing is so ingrained that someone I know took real joy in finally getting to legitimately use this to nuke an old server once the new one was signed off.

Pity he'd not considered that the old one had nfs mounts to the live data...

Re: Recovering deleted files using only grep

#24

Post by existencebox »

Silhouette wrote: post #20
phpdreams wrote: post #16

Earlier quoted context omitted.

This is why every system I administer has 'rm' aliased to 'rm -i' (along with 'cp' and 'mv' just in case). I believe this is the default on RHEL/CentOS boxes. Certainly for root, but should be for every user. Sure, it can be a pain sometimes to have to confirm, but at least you get the chance....unless you add '-f'.

This is why every system I administer has 'rm' aliased to 'rm -i' (along with 'cp' and 'mv' just in case). Glad I'm not the only one. :-) However, that is rather a specific case, albeit a common one. I have lost count of how many times I've seen even very experienced sysadmins do something disastrous by accident that is entirely due to the poor usability of some Linux shell or other command line-driven software with…

Nothing makes you appreciate "don't miss" like deleting /etc on a live system. For a good few weeks after that I nearly introduced a peer review process to my own shell.

That being said, there's certainly something to that one event doing more to reform my being fast and loose with destructive commands than years of being told/telling myself to do so. (Something likely being that I'm apparently a slow learner.)

Re: Recovering deleted files using only grep

#25

Post by gizmo686 »

Silhouette wrote: post #15
moron4hire wrote: post #3

A very important lesson regarding the Unix principles of "everything is a file" and programs that "do one job well".

Also a very important lesson regarding the dangers of poor user interface design. It's a little bit crazy that in 2014 we still have a significant amount of serious work being done on systems where a slip of the finger or a one-character typo in a script can literally destroy whole systems with no confirmation and no reliable recovery mechanism.

We are moving in the right direction with copy-on-write snapshots. What would be neat is an 'immutable' filesystem, where nothing is erased (up to garbage collection). This is likely to extreme to be practical, as we don't want to copy an entire block to change one bit, or read through a journel for every fs action. Even in theory, we don't want do spend the diskspace to record the precise state at every point in time.

Now that I think about it, it shouldn't be to hard to turn this into a workable product for general use. Automatically take a snapshot every 5 minutes, and present a the user a program that broweses the filesystem at time X, probably with integration into the filemanager to restore files/folders. Practically speacking, it needs some form of pruning. Probably along the lines of save every 5 minutes for the past hour, etc. My only concern with this is how optimized for frequent snapshots Btrfs is. Either way, I know what I am doing this weekend.

Re: Recovering deleted files using only grep

#26

Post by ScottBurson »

I once used dd and grep to recover files from a badly corrupted ZFS pool. It was painful. (The cause was a slowly failing PSU -- the +12v line was not holding up under load. So some writes would successfully make it onto the disks and some wouldn't. I don't blame ZFS for failing under such circumstances; but I still wished it had some kind of salvager.)

Re: Recovering deleted files using only grep

#27

Post by lotheac »

gizmo686 wrote: post #25
Silhouette wrote: post #15

Earlier quoted context omitted.

Also a very important lesson regarding the dangers of poor user interface design. It's a little bit crazy that in 2014 we still have a significant amount of serious work being done on systems where a slip of the finger or a one-character typo in a script can literally destroy whole systems with no confirmation and no reliable recovery mechanism.

We are moving in the right direction with copy-on-write snapshots. What would be neat is an 'immutable' filesystem, where nothing is erased (up to garbage collection). This is likely to extreme to be practical, as we don't want to copy an entire block to change one bit, or read through a journel for every fs action. Even in theory, we don't want do spend the diskspace to record the precise state at every point in tim…

> Automatically take a snapshot every 5 minutes, and present a the user a program that broweses the filesystem at time X, probably with integration into the filemanager to restore files/folders.

Something like this? http://java.dzone.com/news/killer-feature-opensolaris-200

Re: Recovering deleted files using only grep

#28

Post by gizmo686 »

lotheac wrote: post #27
gizmo686 wrote: post #25

Earlier quoted context omitted.

We are moving in the right direction with copy-on-write snapshots. What would be neat is an 'immutable' filesystem, where nothing is erased (up to garbage collection). This is likely to extreme to be practical, as we don't want to copy an entire block to change one bit, or read through a journel for every fs action. Even in theory, we don't want do spend the diskspace to record the precise state at every point in tim…

> Automatically take a snapshot every 5 minutes, and present a the user a program that broweses the filesystem at time X, probably with integration into the filemanager to restore files/folders. Something like this? http://java.dzone.com/news/killer-feature-opensolaris-200

That sounds like it is doing something fancier then periodic snapshotting, such as using an immutable filesystem, where every fs operation is inherently lossless (up to garbage collection).

Of course, I might be reading to much into the continous nature of a slider. Does anyone have experience with that feature?

Re: Recovering deleted files using only grep

#29

Post by Silhouette »

gizmo686 wrote: post #25
Silhouette wrote: post #15

Earlier quoted context omitted.

Also a very important lesson regarding the dangers of poor user interface design. It's a little bit crazy that in 2014 we still have a significant amount of serious work being done on systems where a slip of the finger or a one-character typo in a script can literally destroy whole systems with no confirmation and no reliable recovery mechanism.

We are moving in the right direction with copy-on-write snapshots. What would be neat is an 'immutable' filesystem, where nothing is erased (up to garbage collection). This is likely to extreme to be practical, as we don't want to copy an entire block to change one bit, or read through a journel for every fs action. Even in theory, we don't want do spend the diskspace to record the precise state at every point in tim…

There are certainly some very grand schemes we could adopt to improve this specific problem, but let's not overlook the simple things. Every popular OS GUI has included some sort of "recycle bin" concept for a long time. There is no reason at all that a text shell shouldn't provide the same safety net for its delete command.

Re: Recovering deleted files using only grep

#30

Post by a3_nm »

danielweber wrote: post #21
a3_nm wrote: post #17

How could this work? I would expect this method to yield a bunch of matches corresponding to every version of the file that was once saved and continues to live on the disk. Unless you happen to have a string that only existed in the last version or so, but that's hard to come by... I once did recovery of this kind for a friend (using, I think, photorec or extundelete, not grep) and the hardest part by far was piecin…

I don't think there are any guarantees here, but if he kept on saving the same file with the same name, it probably overwrote the same sector on disk.

I guess it depends on the text editor. Some editors will save new versions of a file with the same name by writing the current buffer to a new file and then atomically moving that file to the target location, which has no reason to write on the same sectors.
Post reply on HN