6

Lately, I've been hearing system administrators and managers ask about solutions to keep people from accidentally removing their data. These are very smart and dedicated people asking for a solution so that data isn't lost either by accident or on purpose. A wild idea I've heard to solve the problem is getting rid of user access to the rm command. Is this truly a crazy idea?

Administrators who have users who either accidentally, or sometimes absentmindedly, remove data. The problem they are facing is that the user removes the data, most likely using rm, and then realizes they actually needed the data.

Please tell me the best solution to sort out this problem...???

Jayakrishnan T
  • 298
  • 2
  • 8
  • 22

8 Answers8

10

Regular backups, which are also regularly tested as restores, and a clearly-understood retention policy.

I've also found an informal policy of gently mocking people who ask for restores to be helpful in keeping the number of restores down; hence my distinction (when it comes to backup policies) between what I call disaster recovery and moron recovery. Anything that makes users think a bit before hitting <CR> or clicking "yes" is the best possible medicine against accidental removal, in the long run.

MadHatter
  • 79,770
  • 20
  • 184
  • 232
  • 1
    This is the right thing to do. In additon, to allow users to recover deleted files without admin intervention, you can implement something like this. http://www.mikerubel.org/computers/rsync_snapshots/ – Brian May 11 '11 at 16:10
3

If small losses are acceptable, I think a good backup strategy would be better.

Preventing users from deleting anything will make them angry, and they will always find ways to delete things (for instance with mv or file managers).

Another strategy could be to use a system where every change does not actually remove anything, but just adds up data and metadata.

In such a system, a delete command does not actually destroys any data, it just marks it as deleted, and data can still be restored.

For instance, the open-source ECM Alfresco can be configured in such a way.

user9517
  • 115,471
  • 20
  • 215
  • 297
Nicolas Raoul
  • 1,334
  • 7
  • 22
  • 43
3

Wonder why no one mentioned trash-cli and aliasing rm=trash-cli(a la Sebastian). And you will also have to setup a cronjob to delete the trash folders regularly. Functionally not very different from backup, but still.

Software Mechanic
  • 231
  • 1
  • 9
  • 1
    There are a lot of people who seem to have a religious stance against this. I personally think it's pretty insane that a trash with a 30 day auto delete, isn't the default removal process on servers (like on Ubuntu desktop). The arguments I've seen against it usually fall into the category of false dilemma (https://yourlogicalfallacyis.com/black-or-white) where people pretend that this means you are not implimenting good recovery procedures. There's also a lot of, "well we have always used rm, so why change, just add backups". The attitude makes me sad. – Gerry May 30 '16 at 06:44
  • Ah.. Those people should read http://lesswrong.com/lw/of/dissolving_the_question/ as a pre-requisite for how to argue?. – Software Mechanic May 30 '16 at 11:52
  • Using something like trash-cli seems like a much safer solution than rm. Seems like we are stuck with rm merely for historical reasons. – Adam May 29 '23 at 05:16
2

I've heard of people doing this. My feeling is that there'd be too many edge cases and you'd be increasing your support overhead, since you'll be baking in file hoarding. It's hard enough to get users not to pile up tons of useless files without them having to ask you to delete stuff for them.

You could, for instance, rename rm and wrap it in a script that displays the list of files about to be deleted and makes people type a random 5-letter word from /usr/dict/words to confirm, but bear in mind that whatever speedbumps you put in the way, people can be remarkably ingenious when it comes to circumventing them. Be prepared for unforseen consequences :)

SmallClanger
  • 9,127
  • 1
  • 32
  • 47
2

In addition to making regular (at least daily backups), I simply suggest the forced usage of rm -i. Put in /etc/bash.bashrc:

alias rm='rm -i'

From the manual of rm:

-i     prompt before every removal

or, even better:

-I     prompt once before removing more than three files, or when removing 
       recursively. Less intrusive than -i, while still giving protection 
       against most mistakes
Sebastian
  • 189
  • 6
1

Preventing users from deleting anything will make them angry

This is true. Especially if they own the files they wish to delete, on a system (which is also owned by them). Of course, I use the word own in the traditional sense - clearly Owner Creator quite clearly lists a new, senior domain administrator's SID.

In this hypothetical, it would be owned by the hacker who could not agree more, with Systems Administrators, that End Users are a pain in the...

but, of course I see both points of view.

jonny
  • 21
  • 2
1

Uh removing rm that will help so much... http://perldoc.perl.org/functions/unlink.html cough no, no, just back up religiously.

chx
  • 1,705
  • 2
  • 16
  • 25
1

In addition to making regular (at least daily backups), I simply suggest the forced usage of rm -i. Put in /etc/bash.bashrc:

Though this is a decent solution for simple removals, it does not change anything if someone were to use any other switches with the command. For example, the dreaded rm -rf won't prompt a user because an alternative switch was entered.

Jiminy Cricket
  • 11
  • 1