* NOTE *
In the case of ext3/ext4 file systems, in both the data=ordered (default) and data=writeback modes, shred works as usual.Ext3/Ext4 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.Most Linux distribution come with shred already installed. If not, they are one click away in the repositories. shred is already included, in the multipurpose package called coreutils, which includes tens of utilities.
Using shred:
shred is a command utility. It can be run against files or folders, with certain flags.
# shred -f -u -v -z filename-f change permissions to allow writing if necessary
-u truncate and remove file after overwriting
-v be verbose (detailed) and show progress
-z add a final overwrite with zeros to hide shredding
shred might not work on bad sectors, it is one of the best tools available to securely erase data from your hard disk. It is always more secure to run shred on a complete partition rather than a file, because some filesystems keep backup files and shred makes no attempt to delete these.
# shred /dev/hda2
5 comments:
Shred is a nice tool. However, it's quite limited. If you read the shred man page, you'll see that it's inefective on, e.g., journaled filesystems and RAID-based filesystems.
I just want to know why shred is so damn slow. I started a 500GB hard drive yesterday (early) afternoon and the morning of the next day it's showing 3% done of the 1st pass. That's a pretty useless tool if you ask me.
Interesting - 3% done after > 12hrs!
I started a shred of my external 500GB and after ~3.5hrs, I'm at:
shred: /dev/sdb: pass 1/2 (random)...310GiB/466GiB 66%
If you started shred with no arguments, and you are using an older version, it might be doing 25 random cycles per sector! Bummer!
I started mine with the following command line:
shred -n 1 -v -z /dev/sdb
(where /dev/sdb is my external drive)
Cheers,
tkb.
The explanation for the slowness is on the first page of the manual...
-snip-
--random-source=FILE
get random bytes from FILE (default /dev/urandom)
-snip-
/dev/urandom is not made to provide the industrial quantities of random data needed for erasing a whole hard drive. The algorithm behind it produces a relatively good quality of randomness, at the expense of being CPU intensive. The differences in speed you guys are seeing probably reflect differences in processor power, since that's the bottleneck.
Shred is a useful tool if slow! For my business I look for professional Hard Drive Shredding (speed and security reasons), but personally I use the function. Does anyone know the amount of times you can shred one hard drive?
Post a Comment