Dban fact and fiction:

Dban-ing your data? Read this first!

Dban is "good enough" for most but remember a few things. It does NOT guarantee a complete wipe. Wiping fully 2x is sufficient for total destruction with a few exceptions. Wiping 32 x is a waste of time and this was an idea that came about because older hard drives "MFM" and "RLL" would vary their writing depth based on the frequency of the drive. This could change for several reasons causing the write to go "deeper" in the media and thus more writes could be required to remove the data or not at all in most cases. Guttman is a myth beyond this. The need for this many writes is not true with modern drives, as the way data is stored, and the relation to the depth of the write is no longer dependant on the frequency of the drives write head. However loud noises can cause data to be mis-written due to the vibration of the sound and this is important but I digress. More to the point is that 32x (or whatever) is useless. On MBR disks typically a "quick format" only writes bytes 447 to 512 on the media which destroys the table of "file" pointers to the data and actually leaves the data in tact. When creating a partition the first 0 to 446 bytes *(see note) are written (or overwritten) and this creates/destroys the old data stored there but only there. Both instances of these operations destroy the database(s) stored there but leave bytes 513 to the end of the disk in tact and can be recovered later with a skilled hand. Note this is a little different with the GPT tables but basically the same effect. Only a Full Format will destroy the data and 2 full formats just to be safe. Format with Random data in case you missed anything (*caused by a loud noise hence the 2x formating) which would stand out from the rest of the Zero's you just wrote to the drive. This way any data missed due to _error_ looks like the rest of the noise you wrote randomly.

*Note: This is a "quick" overview of this topic for the purposes of debunking the "Dban" utility as the final solution to data destruction, and is not meant to be exact in the description of other related bytes written to the disk during the formatting of the drive. So don't shoot the messenger.

The exceptions are: Bad sectors "G" list, Bad Sectors "P" list, Wear Leveling:

G list:
Bad sectors can happen at any time from the life of the drive to the death and all drive have 2 tables. This is important because Dban is useless in this case. Dban does not have a function in which it performs any kind of checking to be aware of the bad sector table and does not perform any data recovery and wiping. The Bad sectors are managed by the drives firmware and completely hidden from Dban thus if you have a fragment of a image you shouldn't let's say, and you Dban the drive in which _error_ correction was performed at ANY time by the SMART service on the drive, this sector could have been remapped, marked as bad and left fragments of the image on the sector. Ie. One byte of a 512 byte sector is bad so smart "relocates" or copies this data (or as much as it can read) to a new good sector, but because it can't write, it marks this sector as bad, updates the Bad Sector table, and goes about the day and you never see a thing. Note the rest of the 511 bytes are still there. Dban will skip these sectors. This specific list of Bad Sectors is grown while in use and is specifically known as the "Grown List" or G list.

P list:
There is another set of bad sector tables known as the "Permanent List" and this is the list the drive is mapped with from the factory and can never be changed as it is hard coded to the firmware. This list is created at manufacturer time and because no drive is perfect in manufacturing thus mapping the default bad sectors is necessary to allow the drive to pass testing and be ready to function before it is released to the distributor as a working drive.

Wear Leveling:
On ALL digital media there are limitation as to how many times you can write to the same spot before it burns out. This is because apparently when storing data on an SSD of Flash media of any kind it involves pushing an electron through a "substrate" and lodging it there, which is read later as having or not having a charge (short version). This process leaves a residue behind. The residue will accumulate causing a buildup and eventually be unable to push an electron through and thus a "bad" sector will happen. To prevent this there is e technology called "Wear Leveling". Wear leveling is a small piece of software which will randomly move the disk writes to to another location instead and update the File pointer table or File Allocation Table (FAT). The FAT is a database located at the first 447 to 512 bytes of the storage media which contains the name of the file and where the data associated with the filename is. Magnetic media does not use wear leveling because it can be written to indefinitely as long as there are no defects on the physical media and as explained before is uses the SMART software to update the "G" list if there is a problem. Wear leveling protects the longevity of writes to the drive in this fashion but never actually overwrites any data until all other available sectors are used and it must again (assuming the space is now empty) reuse the same spot. Rinse and repeat.

Conclusion:
To get around ALL of the problem associated with bad sector tables the only solution for total data destruction is not Dban, it is Full Disk Encryption deployed before you ever do ANYTHING else on the media. Full disk encryption is the ONLY way to secure your data from the life to the death of the device. Be careful that you select a sufficiently long password as you don't want a brute force attack to uncover your precious cat videos, and remember that if your disk is decrypted the record you have of "deleted" or "trashcan" files would then be recoverable. Wiping your "recycle bin" on an already Full Disk Encrypted device is a waste of time unless you are expecting to have you password breached, and don't want your deleted file recovered and that's just crazy talk. Don't be careless, use a good password when full disk encrypting and I recommend combining a security token such as RSA or a Yubikey that has no API for recovering the key once it has been written to the device with you current password to secure your data.

"Dban-ing" your data at that point won't matter.