| 1 |
On Mon, Apr 3, 2017 at 2:34 PM, Kai Krakow <hurikhan77@×××××.com> wrote: |
| 2 |
> |
| 3 |
> Just dd /dev/zero to the complete device. That purges everything you |
| 4 |
> need: partition tables, boot sectors, contents: |
| 5 |
> |
| 6 |
> # dd if=/dev/zero of=/dev/sdX |
| 7 |
> |
| 8 |
|
| 9 |
If it contains data you'd prefer not be recoverable you might want to |
| 10 |
use shred or ATA secure erase. |
| 11 |
|
| 12 |
Shred overwrites the drive with random data using a few passes to make |
| 13 |
recovery more difficult. Some debate whether it actually adds value. |
| 14 |
|
| 15 |
Secure erase is a standard command supported by most drives. It has |
| 16 |
the advantage of being MUCH faster, and it also should take care of |
| 17 |
things like relocated blocks and such which might not be seen by the |
| 18 |
OS. It has the disadvantage of being a black box that might not |
| 19 |
actually work or which might have some kind of NSA back door. |
| 20 |
Typically it is implemented by the drive controller encrypting all |
| 21 |
your data transparently using a random key in normal operation, and |
| 22 |
then the secure erase command tells it to forget the key and generate |
| 23 |
a new one. I suspect that secure erase would probably be the closest |
| 24 |
thing to restoring "factory" condition for a drive. |
| 25 |
|
| 26 |
Instructions can be found at: |
| 27 |
https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase |
| 28 |
|
| 29 |
Unless I'm in a hurry I tend to do the best of both worlds. I run |
| 30 |
shred, and then I do a secure erase. |
| 31 |
|
| 32 |
And of course another option is to always encrypt your drives all the |
| 33 |
time anyway, which means that even if the drive fails and you can't |
| 34 |
erase it that your data is secure anyway. |
| 35 |
|
| 36 |
-- |
| 37 |
Rich |
Archives