Home / ubuntu / Questions / 1022331
In Process
Eka
Asked: 2018-04-06 10:02:55 +0800 CST

Wiping free disk space by deleting large amount of files regularly?

  • 772

I was looking for a better way to securely clean free space in my ubuntu system. I found this link and there are some valuable advices to wipe free disk space. I have tried bleachbit method with free disk space option enabled. There are two problems with this method one its very slow and the other it eats up free disk space very fast.

I use bleachbit to clean my system once in every three days with free disk space disabled. This process deletes an average of thousand files per use and also the entire process is very fast.

This is more of a theoretical question; if I carry out this cleaning process in a month I would approximately delete about 10000 files/month. After this cleaning do I stll need to wipe my free space? This is my thinking, when I delete some files new files will be created in its place. When repeated this process the new files overwrite over the deleted files thus making file recovery impossible.

Is my thinking correct? Can this be considered as a secure way to wipe free space in linux/ubuntu system?

ext4 delete hard-drive permanent-delete secure-erase

1 Answers

  1. Erasing parts of a partition or file system

    To erase all traces of what was written earlier (in what is now free space) is not a good idea.

    • If other files are still there, these files may be very interesting for an intruder.

    • Modern file systems with journaling will often have the information in more than one location, and erasing the memory space, which was used for a file is not enough in this case.

    See man shred

     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 sys‐
 tem 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

 In the case of ext3 file systems, the  above  disclaimer  applies  (and
 shred  is  thus  of  limited  effectiveness) only in data=journal mode,
 which journals file data in addition to just  metadata.   In  both  the
 data=ordered  (default) and data=writeback modes, shred works as usual.
 Ext3 journaling modes can  be  changed  by  adding  the  data=something
 option  to  the  mount  options  for  a  particular  file system in the
 /etc/fstab file, as documented in the mount man page (man mount).

 In addition, file system backups and remote mirrors may contain  copies
 of the file that cannot be removed, and that will allow a shredded file

 to be recovered later.

    Wipe a whole partition (with its file system) or a whole drive

    shred and other overwrite tools/methods can be used in a better way to make old information harder to read, when you wipe a whole partition or a whole mass storage device (the whole drive) instead of individual files or the drive space between the files.

    Encrypt the whole file system

    But I think that the best way is to encrypt the whole file system with a very good password. This way nothing, not the current files, and not deleted files are possible to read without the password.

    Warning: if you forget the password, the data are lost for you too. If the file system is damaged, it is difficult to recover. So you need a good backup, that is stored in a safe place, and a good backup routine to keep your backup up to date.

    Ubuntu's installer has an option 'LVM with encryption', which uses LUKS encryption for the root file system. This is often referred to as 'encrypted disk'. See this link,

    Install (entire disk with lvm and encryption)

    • 3