recovery of deleted files ? debugfs use?
 

Please don't laugh! Well OK, laugh, then please help (-: I have managed to delete some files I would rather still have. Specifically some files I finally completed at 1:30. I should know better. I did an rm -rf on a symlink and the whole dir is gone. Quel surprise

Reading around the issue I came across debugfs.
$debugfs /mnt/laria gives me
debugfs 1.41.12 (17-May-2010)
/mnt/laria: Attempt to read block from filesystem resulted in short read while opening filesystem

I don't know what this means. Can someone tell me, please.

I am a student, logged onto this machine remotely. I do not have installation rights. I have been a linux user for ~6 months

The os is Linux version 2.6.35.6-45.fc14.x86_64 (mockbuild@x86-02.phx2.fedoraproject.org) (gcc version 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) ) #1 SMP Mon Oct 18 23:57:44 UTC 2010

I have also seen the threads about extundelete. Is this the best tool available? (I may be able to get my supervisor to install this)

Thank you, and have a great weekend. If you can make mine better please do ... (-:
M

In the new release it doesn't work anymore!!!!

extundelete doesn't work?
 

That sounds like a retrograde.

I've just come across scalpel. Does anyone have any experience of this?

TIA

M

Abandon All Hope. Period
 

Because you don't control this remote machine you won't be able to use tools (the undelete functionality of testdisk, photorec, TSK, foremost, scalpel) as they require admin rights to run. And even if the admin would grant you additional rights (that would show proof of incompetence IMNSHO), the way these tools work there's the potential of undeleting data you should not be allowed access to like privileged system information or private data of users. Finally, as it's a multi-user machine it's safe to assert its own system processes and other user processes use and free disk space as needed, potentially overwriting any remnants, and the way modern file systems work recovery becomes exponentially harder with each second processes are allowed to re-allocate disk space.


* Did anything positive come out all of this? Well yes, but it's probably not a lesson you would have liked to learn this way: you finally experienced the importance of making backups...

Fair comment. My backups do exist but are a few days && a lot of head-scratching ago. And a whopper of a re-design.

Does anyone know if vi can be set up such that every time you do a save it will also do a save to /somewhere/else/entirely/preciouswork.bak ?

On my current predicament, I've already tried Scalpel on my home machine & that doesn't seem a likely solution. Not least because in my hands it finds files, writes them to the output directory (presumably), but that dir them appears to be empty. I've had a good google & ownership of the dir is not the issue.

Can anyone offer comments on extundelete? I might be able to persuade my supe to install that.

Thanks

M

That's a shame.


But I'd really advise against doing that and I would strongly advise you to use versioning, be it RCS, CVS, GIT or whatever else you fancy, instead as it's easy to use, efficient, application, host and OS independent.


If you search LQ for "undelete" or "recovery" threads you'll find quite a lot of detailed responses including recovery scenarios (hell, some even with positive results) and if you want a recommendation I'd suggest starting with photorec instead as its signature lists are more up to date than foremost or scalpel. (Use the undelete functionality of 'testdisk' only right after deletion.) The problem however is that for any chance at recovery (and I didn't say "successful" OK) a 'dd' backup of the partition should have been made as soon as the deletion was noticed. Sure unlinked data may still reside in areas of a disk if that portion is not written to but the way journalling file systems work deletion will be difficult so as soon as the partition gets written to secondary and tertiary indirectly linked blocks will be the first to go out the window, leaving you with incompletely recovered fragments possibly even with fragments of other files intermixed or appended.

Those Vi hints are useful. Thank you. I take on board yr comments about versioning. I'm not sure right now I can steepen my learning curve still more, though. (it's been a tough day) which would you recommend more specifically?


I've just checked out the users on this machine. Today it's been me and my supe, running an overnight job. My understanding might be awry here, but he's using tools from /usr/local/, & reading & wrting from /mnt/; my files were in my /home area; aren't these devices likely to be mapped (?assigned .. sorry not sure of terminology) to different partitions? And hence the space my unintentional delete 'freed' up might not necessarily have been written over already?


Or should I just give up (as advised)? That's a heck of a way to start a New Year, though, especially if I mean to go on as I started!

More positively, is a 'dd' backup of the /home partition something I can do without root access? How would I determine whihc partition hosts /home? Or is this something I need to ask my supe to do?

Thanks for your input. It's easy to recognise expertise when it's offered.

M

After all these years I still use RCS for logging local configuration file changes and CVS for remote work (SourceForge). For both you basically need to know only two commands: check in ('ci') and check out ('co'). If that looks interesting have a look at say
http://linuxdevcenter.com/pub/a/linu...cvs_intro.html
http://mongers.org/cvs
http://cvsbook.red-bean.com/cvsbook.html
...or your choice of hits using your favorite search engine with a phrase like "introduction to using CVS".


If the deletion happened today or yesterday and no process has written to /home (the system updating user and group quotas, an MTA delivering email locally if no /var/spool/mail is used, users transferring files over FTP, logging in and out of their account or running cron jobs are just some examples and even then what you call /home may be a NFS share) then you have slight chance. And no, unfortunately you need root rights to make a 'dd' copy of a partition. If the admin can make a backup (in its simplest form 'dd if=/dev/partitionname of=/mnt/mountpointname/filename.dd') then maybe that backup may be stored on another system, maybe one where they wouldn't mind installing and running photorec or any other tool of choice. If all of that succeeds you should hash your backup files ('sha1deep -p 1k -r /path/to/your/backup > /path/to/your/backup.sha1') so the admin can run 'sha1deep -p 1k -m backup.sha1 /path/to/recoverd/files' as that would make it easier to pinpoint fragments to share without giving you access to all files. Even still there may be unwanted data so the admin should inspect files visually before handing them over.



You're welcome. I'm no expert however just another average fellow Linux user.