How to remove a file so that it becomes almost non-recoverable.
If you’ve ever used the infamous
rm
command to remove something on Unix or Unix-like systems, then let me tell you something that will take you by a hurricane, the‘rm’
command never exactly erases the entire file. That file is still in the system and is totally recoverable with the right techniques.Read on to know what you can do to completely remove a file and also make it non-recoverable.
There’s a command that goes by the name, shred
which helps us to wipe out disks and clear files in a secure fashion.
What actually is the Linux command shred
and how is it different from rm
?
Okay, so simply using the rm
command doesn’t actually remove the file, it just removes the pointer that was pointing to that file. The actual data might still be there. Surprised? let’s head over to the Wiki reference of the command rm
.
The
rm
command removes references to objects from the filesystem using the unlink system call. The command generally does not destroy file data, since its purpose is really merely to unlink references, and the filesystem space freed may still contain leftover data from the removed file. This can be a security concern in some cases…
But when you use the shred
command, the file is overwritten a specified number of times in a way that the actual content is unrecoverable. Which makes the data nearly non-recoverable.
Let’s see an example of shred
command in action,
I’ve got a colors.txt file on my system, let’s see what it has using the command cat colors.txt
Let’s also head over to the man page of shred
command, before using it.
so we can use shred
with option/s and then file/s to be shredded.
let’s peek more into the options:
now it’s time to use the command shred
with our colors.txt file,
shred -v colors.txt
, -v is for the option of viewing the process of shredding.
Great, works like wonder. Here you can see 3 passes in action, it means that the file colors.txt
was overwritten 3 times. How can I be so sure of the overwriting? Let’s just display the file back and see for yourself:
using cat colors.txt
You can see that the file has been overwritten into some gibberish by the shred
command.
After this we can simply remove this file, using the rm
command. Or to make shred
more effective we can simply use it with its inbuilt option -u, which de-allocates and removes the files after overwriting it.
Using the command, shred -vu colors.txt
-v : to show progress, and -u : to remove it totally.
Here you can observe three things in action, : 3 passes to overwrite the file with random stuff, then renaming the file name to 0 and then ultimately removing it.
Let’s now jump into the more useful part of shred
command, that is to securely erase a storage device, shred
will overwrite the entire data in that file, making it nearly impossible to recover. Check it out on Ask Ubuntu
Concluding this all
shred
makes sure the data is overwritten and is nearly impossible to recover. If safety is the foremost concern then shred
is a wonderful option against widely used rm
. But shred
is little slow as compared to rm
. I remember shredding my disk of size almost 4 gigs and it took me 20mins in doing so. Yeah, shred
is little slow, uhh, let’s just stick to ‘slow’ for now.
CAUTION: Note that shred relies on a very important assumption: that
the file system overwrites data in place. This is the traditional way
to do things, but many modern file system designs do not satisfy this
assumption. The following are examples of file systems on which shred
is not effective, or is not guaranteed to be effective in all file system modes:* log-structured or journaled file systems, such as those supplied with
AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)* file systems that write redundant data and carry on even if some
writes fail, such as RAID-based file systems* file systems that make snapshots, such as Network Appliance’s NFS
server* file systems that cache in temporary locations, such as NFS version 3 clients* compressed file systems
Hey, if you were amused by this article do give me a follow. I love the command line and I call myself an artist whose art is programming.