If you’ve ever used the infamous
rmcommand 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
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
rmcommand 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
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:
You can see that the file has been overwritten into some gibberish by the
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
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.