Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I know that most files, when deleted, aren't actually removed from the disk, and can be recovered later.

How can I ensure that a directory I had deleted will actually be removed from the disk? Are there utilities for that?

I'm using Debian Linux.

share|improve this question
5  
The short answer: You cannot! The long answer: Either physically destroy the disk or rephrase the question: How much effort would it take to recover the data and what would be the success rate of such an attempt? –  Marco Feb 1 '13 at 11:48
add comment

2 Answers

up vote 5 down vote accepted

Encrypt the data before storing it. To erase the data, wipe the key.

If you've already written the data in plaintext, it's too late to wipe it in a simple way. There may be multiple copies of the data laying around in various places:

  • on the filesystem if the file was written multiple times (either overwritten or replaced);
  • on the filesystem if it was rearranged as part of defragmentation;
  • in the journal (this is likely to disappear pretty fast after the data was last written);
  • in backups;
  • in disabled sectors (especially on SSD).

To get rid of copies of the data on the filesystem, a crude method is to fill the free space (cat /dev/zero >somefile and wait for it to stop because the filesystem is full). This will overwrite all full blocks.

Small parts of the data may remain in incomplete blocks that are partially used by other files. This is especially a concern for file names, which may remain in blocks that store directory contents. To get rid of everything, back up all the files, overwrite the device containing the filesystem completely, then restore the files.

Storage media may retain data in blocks that are no longer in use. On hard disks, this means bad blocks that have been reallocated; this is a pretty rare occurrence until the disk starts wearing down. On SSD, this is a common occurrence due to wear levelling. In both cases, the threat is very low, because accessing that data requires a somewhat sophisticated attacker with some moderately expensive hardware and time to waste. If you care about these threats, encrypt your data and don't leave your key lying around.

Note that you may see advice about erasing data by doing multiple passes or using random data instead of zeroes (“Gutmann wipe”). Forget it: this applies only to 1980s hard disks (and even then the data is not that cheap to reconstruct and the reconstruction is rather unreliable). Overwriting with zeroes is good enough; doing multiple random passes is obsolete advice or snake oil. See Why is writing zeros (or random data) over a hard drive multiple times better than just doing it once?

share|improve this answer
add comment

There is a very popular tool called shred. It will overwrite every file 25 times before it will be deleted. That might me what you are looking for.

Usage of shred is quite simple

$ shred secret_archive.tar.gz

Note however that on modern systems shred might be inefficient or useless if:

  • Your programs create temporary files you are not aware of (Like many GUI Applications)
  • Your FS is Copy-On-Write based (Like ZFS or Btrfs)
  • Your FS is log based (Like NILFS)
  • Your FS uses data journaling (Like JFS, ReiserFS, XFS, ext3 or ext4 in some configurations)
  • Your FS uses compression
  • Your FS allocates new versions of files at different locations
  • You have snapshots or Back-Ups
  • You are on a network FS
  • You are using an SSD with wear leveling algorithms

Other and potentially more secure options are:

  • Encrypting critical data
  • Overwriting the whole partition or storage device
  • Physical destruction of the device
share|improve this answer
    
According to my manpage shred works even with ext3 (and I guess ext4, too) when using data=ordered (default) and data=writeback modes. Furthermore there is a simple alternative: just create a huge file occupying all of the remaining space of the file system so that your deleted file will get overwritten. –  scai Feb 1 '13 at 12:20
    
Thanks. I just fixed it. journaling -> data jornaling –  taffer Feb 1 '13 at 12:23
    
@scai, the huge file method won't necessarily work as the file's blocks may have already been reallocated and not written yet (like falloced data, last block of files or dirs...) –  Stephane Chazelas Feb 1 '13 at 12:44
3  
shred is snake oil: it is no better than head -c $(wc -c secret_archive.tar.gz) >!secret_archive.tar.gz`. Using shred is always pointless unless you're using a hard disk from the 1980s or early 1990s. –  Gilles Feb 2 '13 at 0:48
2  
shred/bcwipe/etc. are snake oil on a filesystem level. For any filesystem. Because of the way you work with files: Every time you click save, the old file is deleted (resides in free space), and a new file created. You can't shred it if the filesystem has already forgotten about it. -- It's different on device level, or overwrite-all-free-space level. There shred is one of the few fast random data sources available in Linux/Unix. /dev/(u)random it too damn slow to be usable for overwriting large amounts of data. -- So a single shred pass is OK for device or free space, just not for single file –  frostschutz Feb 3 '13 at 17:43
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.