3

I need to wipe a hard drive before I give it away, but I want the ability to do so in portions so that I can stop and resume at various points in the middle. For instance, if it will take 24 hours to wipe the disk but I only have blocks of 6-8 hours each night available, I would like to plug the USB hard drive into my laptop to wipe overnight, unplug and take my laptop away in the morning, then resume the next night until it's completely done.

I am using dd from a Linux terminal e.g.

$ nohup dd if=/dev/zero of=/dev/sdX bs=1M &

I originally thought of simply monitoring its progress with kill -USR1 ${ddpid}, keeping track of it, and then resuming where I left off following interruptions. I was immediately not fond of this as I messed up on the math on the first attempt and lost time re-wiping an already-wiped area.

I'm now considering partitioning the drive in advance, and then wiping each partition one at a time or a couple at a time. Since it's a 4 TB disk, I couldn't reach past the 2-TB boundary using fdisk, so I used gdisk to create new partitions:

Device          Start        End   Sectors   Size Type
/dev/sdb1        2048  589826047 589824000 281.3G Linux filesystem
/dev/sdb2   589826048 1179650047 589824000 281.3G Linux filesystem
/dev/sdb3  1179650048 1769474047 589824000 281.3G Linux filesystem
/dev/sdb4  1769474048 2359298047 589824000 281.3G Linux filesystem
/dev/sdb5  2359298048 2949122047 589824000 281.3G Linux filesystem
/dev/sdb6  2949122048 3538946047 589824000 281.3G Linux filesystem
/dev/sdb7  3538946048 4128770047 589824000 281.3G Linux filesystem
/dev/sdb8  4128770048 4718594047 589824000 281.3G Linux filesystem
/dev/sdb9  4718594048 5308418047 589824000 281.3G Linux filesystem
/dev/sdb10 5308418048 5898242047 589824000 281.3G Linux filesystem
/dev/sdb11 5898242048 6488066047 589824000 281.3G Linux filesystem
/dev/sdb12 6488066048 7077890047 589824000 281.3G Linux filesystem
/dev/sdb13 7077890048 7667714047 589824000 281.3G Linux filesystem
/dev/sdb14 7667714048 7814037134 146323087  69.8G Linux filesystem

I'm running dd backwards from sdb14 down to sdb1 just so I can keep things straight.

As I complete each partition, I'm considering going back into fdisk/gdisk and deleting the partition even though the full disk isn't wiped.

Once I'm done with all the partitions, I'm planning to wipe the beginning of the disk as well:

$ dd if=/dev/zero of=/dev/sdX bs=1M count=512

(I understand 512 is a bit excessive; please feel free to provide a better number in the comments.)

Will this accomplish my goal of wiping the disk in full, pieces at a time, without leaving any missed gaps anywhere?

jia103
  • 564
  • 1
    I would just use VeraCrypt a single 4TB partition, suspending the operation between each session, then simply removing the partition when it's completed. If you encrypt the data, then delete the partition, nothing can be restored without your password. – Ramhound Dec 07 '17 at 04:51
  • Did you check to see if the drive already implements secure wipe? – Ignacio Vazquez-Abrams Dec 07 '17 at 06:23
  • A note on getting the progress of dd: you can run newer version of dd with the option status=progress and you will get the current status all the time. The output with this option looks like this: 462858752 bytes (463 MB, 441 MiB) copied, 38 s, 12,2 MB/s. So no need for kill -USR1. – Sethos II Dec 07 '17 at 12:00
  • If would be safer to use /dev/urandom as a source (even safer with /dev/random but not much safer and much, much slower....). – xenoid Dec 07 '17 at 13:46

2 Answers2

1

Another alternative to @KamilMaiorowski solution would be to create a filesystem on /dev/sdX, then write empty files on it. In this way you can stop part way, and continue at will, either by appending to the file or writing a new one. Once the disk runs out of space for more files you are done. You can also delete the files from the disk once you have done so.

To do this (from a bootable disk)

mkfs.ext4 /dev/sdX
mkdir /tmp/tempdisk
mount /dev/sdX /tmp/tempdisk
dd if=/dev/zero of=/tmp/tempdisk/file0.zero
davidgo
  • 70,654
  • This seems like a good try, but in general I'm not yet convinced from a thoroughness perspective. Assuming a sector size of 4 KB, if I happen to press Ctrl+C right when dd wrote to Byte 0 of a given sector, I believe I will be left with 4095 bytes of inaccessible and unwiped storage allocated to file0.zero but never used, and therefore not zeroed out. – jia103 Dec 08 '17 at 02:31
  • No, you wouldn't - because the block size of a write is 4k, so it would not flush the write to disk at byte 1. That said, you raise a good point - you shsould through the option bs=4096 (or some multiple thereof) to ensure dd works in blocks which are a multiple of the sector size. – davidgo Dec 08 '17 at 02:49
0

About the beginning of the disk. The first partition starts at the sector 2048. Sectors are numbered from 0. The provided gdisk output doesn't state it explicitly but I can calculate your disk uses sectors of size 512B. So there are 2048 sectors of 512 bytes before the first partition. This command will fill them with zeros:

dd if=/dev/zero of=/dev/sdX bs=512 count=2048

Will this accomplish my goal of wiping the disk in full, pieces at a time, without leaving any missed gaps anywhere?

I have analyzed the numbers – there are no gaps between partitions. But! GPT scheme places backup partition table at the very end of the disk, it takes 33 sectors. Additionally partitioning tools may align the end of the last partition somehow (although the odd number of 146323087 suggests it's not the case here). So you should also cover this space beyond the last partition:

dd if=/dev/zero of=/dev/sdX bs=512 seek=7814037135

Expect this command to reach the end of the disk almost immediately.

Disk operations use cache so you should run sync after all of this. Normally all the cache is flushed when you shutdown gracefully. But if you disconnect the disk (unplug USB) earlier, some changes may be lost. Let's hope you never disconnected this way after wiping particular partitions.

After this your whole disk will be zeroed. This should be enough (read this and this). If the disk was SSD there might be some concerns because of wear leveling; but I guess 4 TB here is HDD so there's no issue.

Kamil Maciorowski
  • 74,068