A.P. Lawrence

2005/04/15 shred

Shred tries to really remove any trace of a file from a disk. It seems like such an easy thing to do: even if you already understand that "rm" merely disassociates data blocks from an inode and returns them to the free list, why wouldn't just overwriting the file with a bigger file destroy the data? Well, because disks are mechanical devices and storage is quite fuzzy, so weak images of previous data are still present after a simple overwrite. Also, disk heads may move slightly out of track over time, leaving a magnetic trail "off to the side". Those problems and more are discussed in depth at Secure Deletion of Data from Magnetic and Solid-State Memory by Peter Gutmann.

Most of us have no need for such forensic obstructing scrubbing. Good thing that we don't, because the "info shred" page tells us that "shred --verbose /dev/fd0" could take 20 minutes. It's a bit quicker at running through a hard drive file but it still takes noticeable time.

Should you really need to do such a thing, be aware that there are lots of things that can trip you up - ordinary disk caching prevents "shred" from really doing what it intends. You can use "chattr +S" on the file before running shred to get the writes forced through the cache. Using "shred" is probably fine if you are giving away a computer and don't want its next owner to see your data (in which case you shred filesystems rather than files), but if you have serious reasons to need data securely destroyed, physical destruction of the media is the only real answer.

With Linux ext3, "shred" is a bit less necessary (from http://batleth.sapienti-sat.org/projects/FAQs/ext3-faq.html):

Q: How can I recover (undelete) deleted files from my ext3 partition?

Actually, you can't! This is what one of the developers, Andreas
Dilger, said about it:

In order to ensure that ext3 can safely resume an unlink after a
crash, it actually zeros out the block pointers in the inode,
whereas ext2 just marks these blocks as unused in the block bitmaps
and marks the inode as "deleted" and leaves the block pointers
alone.

Your only hope is to "grep" for parts of your files that have been
deleted and hope for the best.  

HOWTO recover deleted files on an ext3 file system disagrees:

However, this is utter nonsense. All information is still there, also the block pointers. It is just slightly less likely that those are still there (than on ext2), since they have to be recovered from the journal. On top of that, the meta data is less coherently related to the real data so that heuristic algorithms are needed to find things back.

On February 7th, 2008, I accidently deleted my whole home directory: over 3 GB of data, deleted with rm -rf. The only backup that I had was from June 2007. Not being able to undelete was unacceptable. So, I ignored what everyone tried to tell me and started to learn how an ext3 file system really works, and what exactly happens when files are deleted...

Three weeks and nearly 5000 lines of code later, I had recovered every file on my disk.

Comments /Words2005/2005_04_15.html


Fri Oct 21 14:01:23 2005: Subject: less necessary?   Dan
AFAIK ext3 does NOT zero out the data, only the pointers that tells the FS where the data is. So "not-shredding" your data WILL leave your data readable on the disk, you just have to search a little harder to get at it.



Now, whether shredding is actually works on a journaling system is another story. (Which was btw, was what i was searching for a answer to myself :))

Fri Oct 21 14:17:26 2005: Subject:   TonyLawrence
The developer seems to agree :-)



Add your comments

Why no "Digg this!" etc.?

Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here