This thread got me thinking about the times that I've done an accidental 'rm
-rf' as root. It's happened three regretable times in the past 10 years.
The procedure for all three times was like so:
1. Open up at least three terminals with at least two root shells
2. Make sure one root shell is in / and the other in the current working dir
3. Do something in the current working dir in preparation for deleting it's
contents
4. Switch to third terminal and do something there
5. Accidentally witch to / terminal but ASSUME that it's the current working
dir terminal
6. Without actually checking the pwd, do a 'rm -rf *'
7. Notice after awhile that it's taking far too long and making the disk drive
much too noisy. Stop it. Realize that it's nuked /etc, /bin, and much of
/home
8. Weep, moan, nash teeth once realization hits that no backups have been made
in the past few months
Since then I've safeguarded myself against this a bit by a) making sure root's
shell prints out the pwd in the shell prompt b) ALWAYS doing a 'pwd' and 'ls'
before removing directories c) making much more frequent backups
Step 7 in my list ("rm taking far too long") gave me the idea for a possible
way to help recover from an accidental rm -rf. Here is the background:
1. In my experience, nuking everything too long enough that I was always able
to stop it well before it finished.
2. 'rm -rf' seems to work alphabetically
3. Hard links take up very little space yet keep a file from being deleted
until all links are destroyed
So say you create a directory called /zzlinkmirror that mirrored all of the
directories that you had on that disk. Then, you make a hard link (NOT
symbolic link) for each file on that disk. You would end up with a directory
tree that completely mirrored your system but took up almost no space.
A cron job could run every night to update your mirror.
Then, if you do a 'rm -rf *' in / and notice it after nuking /etc and /bin,
you can stop the 'rm' and do something like 'mv /zzlinkmirror/bin /bin' and
'mv /zzlinkmirror/etc /etc'
The key here is that you must be able to stop the deleting before it gets to
your mirror directory.
Pluses and minuses of this system:
+ Ultra-fast and accurate recovery of most directories and files
+ Takes up almost no space
+ Easy to setup and keep going with a cron job
- Doesn't work if rm -rf completes
- Doesn't have any concept of revisions (but then, that's the realm of a full-
fledged backup scheme which is an entirely different animal)
- You can't make hard links to special files like sockets and device nodes
What do y'all think?
Kurt
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change you mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)