(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version



shred

2005/04/15



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.




Click here to add your comments





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

gravatar
The developer seems to agree :-)

Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments


If you want a picture to show with your comment, go get a Gravatar



ad

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

Jump to Comments



Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.


book graphic unix and linux troubleshooting guide

My Troubleshooting E-Book will show you how to solve tough problems on Linux and Unix systems!



 I sell and support
 Kerio Mail server




pavatar.jpg
More:
       - Security


Unix/Linux Consultants

Skills Tests

Guest Post Here











My Favorites

Change Congress