18

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.

2

3 Answers 3

17

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?

2
  • "wipe the key" -- on an ssd, i suppose you can't reliably wipe the key either; so perhaps it would make sense to overwrite everything
    – Toothrot
    Commented Aug 2, 2020 at 14:27
  • @Toothrot Supposedly, you don't store the encryption key on the same media as the encrypted content. Doing so would, in effect, be the same as not encrypting the data.
    – Kusalananda
    Commented May 26, 2023 at 11:46
15

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
5
  • 1
    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
    Commented Feb 1, 2013 at 12:20
  • Thanks. I just fixed it. journaling -> data jornaling
    – taffer
    Commented Feb 1, 2013 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...) Commented Feb 1, 2013 at 12:44
  • 4
    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. Commented Feb 2, 2013 at 0:48
  • 4
    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 Commented Feb 3, 2013 at 17:43
0

bcwipe still has its uses. Not privacy. Who else zero-fills the free space on my ProxMox kvm machines? That is expressed in 20 times reduction in vzdump size for a kvm machine having a lot of free space. It has the same amount of free space as before, only it's only zeros, and these get archived with a high rate of compression.

1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .