LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   Sir my subordinate used rm -rf command in root directory by name direcectory as 123. (https://www.linuxquestions.org/questions/linux-newbie-8/sir-my-subordinate-used-rm-rf-command-in-root-directory-by-name-direcectory-as-123-a-4175530309/)

srrmohan 01-07-2015 06:32 AM

Sir my subordinate used rm -rf command in root directory by name direcectory as 123.
 
Sir my sub-ordinate used rm -rf command in /root derectory duly deleting 123 directory which is in /root which has 5years periodicals data lost. Duly undelete command unable to rectify because gcc was not installed in that client. Tell me the correct way to recover
-SRR MOHAN

rtmistler 01-07-2015 07:02 AM

Try PhotoRec. I've used it to recover files which were deleted using an rm -rf command.

allend 01-07-2015 07:27 AM

Sir, my usual response to a first time poster is to say "Welcome to LQ!', but here I am constrained by my troll detection meter being hard on the peg in the red zone.
Your post says nothing about the file system in use.
There is no undelete command in Linux.

Recovery procedures should include:
1. Firing the incompetent who allowed a subordinate access to such a powerful command.
2. Firing the incompetent who allowed 5 years of data to be lost without a backup strategy.
3. Firing the incompetent who needs to ask a question like this on this forum.

If this is serious, first isolate and image the disk. You may be able to recover using a tool like extundelete or similiar. http://extundelete.sourceforge.net/

Habitual 01-07-2015 12:59 PM

Ouch. So you've had a backup plan for 5 years you say?

John VV 01-07-2015 01:49 PM

NEXT time
DO NOT GIVE THAT PERSON THE ROOT PASSWORD!!!!!!!!!!
if that person STILL has a job
and if YOU STILL have you for allowing someone to do that


reinstall and learn a valuable lesson

also NEXT TIME
do not use the root $HOME folder to store files
"/root" is not a good place to STORE things

dugan 01-07-2015 01:57 PM

Quote:

Originally Posted by allend (Post 5297005)
Recovery procedures should include:
1. Firing the incompetent who allowed a subordinate access to such a powerful command.
2. Firing the incompetent who allowed 5 years of data to be lost without a backup strategy.
3. Firing the incompetent who needs to ask a question like this on this forum.

4. Firing the incompetent who stored that much important data in /root and nowhere else.

John VV 01-07-2015 02:08 PM

ok i think the OP is getting the point

WE ALL have done things like this in the past ......

rtmistler 01-07-2015 02:16 PM

Yeah, yeah. OP, go add your experience to the following thread I'm an idiot moments.

Like others have said, do not store stuff in the /root tree. Be more cautious about backing up critical data, and how you disseminate control/access to the system.

You're not much of a mentor if you've let a subordinate cause this much mayhem.

In the meantime, try Photorec, as it really does work.

TB0ne 01-07-2015 02:47 PM

Quote:

Originally Posted by srrmohan (Post 5296978)
Sir my sub-ordinate used rm -rf command in /root derectory duly deleting 123 directory which is in /root which has 5years periodicals data lost. Duly undelete command unable to rectify because gcc was not installed in that client. Tell me the correct way to recover

Others have covered the big points here, so there's no need to rehash them. That said, you really do need to read the "Question Guidelines" link in my posting signature.

You say you 'duly' ran the undelete command...which wont' do anything, especially since Linux doesn't HAVE an 'undelete' command. You don't tell us what version/distro of Linux you're using, what the message(s) were that you got when you tried this (only something vague about gcc), or what (if anything) your backup strategy consisted of.

If you are an administrator, and you have been:
  • Letting users log in as root (or have root privileges)
  • Going for YEARS without a backup
  • Keeping files in the /root directory
...you really need to perform some basic job training. I'm sorry if it sounds harsh, but there are MANY good reasons why you don't do these things. The best way to recover what you lost (that is, five-years worth of periodicals), is this:
YOU and your subordinate get the hard copies of the five years of periodicals, and start typing them back in.
It will be a hard job, and take many, MANY hours. It will also be a lesson you and your subordinate never, EVER forget. You MAY be able to dodge a bullet by using photorec, but at this point, I'd say your chances are slim. Take your medicine, no matter how bitter it is, and learn from it. And the next time, this won't happen to start with, and if it DOES, you'll be totally prepared.

Andy_Crowd 01-08-2015 01:05 AM

By myself I am using /root only for back up of system settings when I testing or removing some of system files folders. User backups I use to make in the /opt folder, usually user settings for people to whom I install Linux too in case if they will play with installed programs or will remove files, they will be able to run a script that will restore them, e.g. by writing restore in the command line or in run window.

It takes a lot of time to restore deleted file so I recommend to make an compressed image of the whole disk or partition where files were deleted from that you will be able to mount. Then mount it and run photorec.

pan64 01-08-2015 02:15 AM

it was already mentioned: noone can be admin without executing rm -rf / at least once in his/her life....
The solution should be to restore files from backup - that is a serious issue if there was no backup (but actually it was mentioned too: important data always saved, if your files were not saved they were not important at all).
There is a tool named testdisk, you can try to use that to recover lost files, but first you need to lock that drive or make a full image (using dd) of it, otherwise you will lost even the possibility to find anything on that drive).


All times are GMT -5. The time now is 09:34 AM.