EDITAR:OP siente que la respuesta original no está a la altura de los estándares SE. Lo dejo abajo. Respuesta más reciente aquí:
Dos opciones para un borrado completo del disco. El primero aprovecha las capacidades de borrado seguro del controlador de la unidad de disco, pero no todas las unidades tienen la capacidad y algunos BIOS bloquean el comando. Es más rápido que la segunda opción.
- Eche un vistazo a hdparm:
hdparm --security-erase <PWD> <device> - Echa un vistazo a limpiar. Puede recuperar el borrado con
apt-get install wipey limpia un disco conwipe /dev/sdb1.
Además, aquí hay mucha información sobre cómo borrar las unidades de Linux, incluidas las secciones en hdparm y wipe .
RESPUESTA ANTIGUA
¿Golpeaste cada parte del camino? ¿Qué pasa con los archivos de intercambio? ¿Qué pasa con los directorios /tmp? ¿Qué pasa con los archivos que ya fueron eliminados? Realmente necesita presionar cada byte eliminado o no aún en la unidad que el sistema operativo no usa actualmente. Entonces, ¿qué pasa con los sectores defectuosos que el controlador de disco aisló automáticamente? Ya no puede acceder a ellos, pero un servicio de recuperación de unidades podría hacerlo.
Me pregunto si escribe un programa que acceda a los controladores del dispositivo de disco directamente (/dev/disk0 en mi máquina) y lo sobrescriba desde allí. Sería un poco relativamente pequeño de código C. El programa se leería en la RAM y se ejecutaría hasta que se borre el disco. Sin embargo, el sistema operativo ya no funcionará después de eso, y definitivamente no después de reiniciar. Entonces, solo puedes hacer esto una vez.
Las agencias más paranoicas solían aplastar y ahora triturar físicamente sus unidades de disco. A veces las personas no hacen lo que prometen que harán.
¿Qué tan paranoico eres?
Puedes ejecutar shred directamente en el nodo del dispositivo del disco desde el sistema en ejecución. Será infeliz y generará errores de IO ya que el sistema de archivos aún está montado en un disco que se llena con datos aleatorios, pero como el shred el binario y cualquier biblioteca de la que dependa estén completamente cargados antes de que comience el proceso, debería ser capaz de resistir todo lo demás colapsando bajo los errores de IO y aun así completar el procedimiento de borrado.
Tenga en cuenta que existe una pequeña posibilidad de que los datos confidenciales se vuelvan a escribir en el disco después se ha borrado porque el sistema de archivos todavía está montado en lectura/escritura y el sistema podría estar descargando búferes llenos de datos confidenciales de vuelta al disco. Para mitigar esto, vuelva a montar el sistema de archivos como de solo lectura si puede, aunque estoy bastante seguro de que no puede hacerlo fácilmente desde el sistema de archivos raíz una vez que el sistema se está ejecutando. Puede modificar su fstab para montarlo usando el ro y reinicie (pero asegúrese de que su proceso de arranque no le importe y que al menos pueda llegar lo suficientemente lejos como para iniciar un servidor SSH para que pueda conectarse), o desde una consola física/dispositivo de administración fuera de banda, inicie el sistema operativo con una línea de comando de kernel personalizada linux /boot/vmlinuz... root=/dev/sdX ro quiet init=/bin/sh que monta el sistema de archivos raíz como de solo lectura e inicia un shell simple en lugar del proceso init, y desde allí debería poder ejecutar shred sin fugas de datos ya que el FS ahora es de solo lectura.
Tenga en cuenta que si tiene particiones de intercambio configuradas en el dispositivo que está borrando, asegúrese de "desmontarlas" con swapoff /dev/sdXY (o comentándolos en fstab y reiniciando) antes de borrar el disco para garantizar que el proceso pueda completarse sin problemas. Si bien los errores de IO no son fatales para un proceso que ya está cargado, jugar con la partición de intercambio puede hacer que el sistema se bloquee por completo antes el borrado se ha completado.
Finalmente, otra opción es el comando ATA Secure Erase:
hdparm --security-set-pass verysecure /dev/sdX
hdparm --security-erase verysecure /dev/sdX
Suponiendo que confíe en que el fabricante de la unidad lo implementará correctamente, esto debería ser suficiente, pero todo lo anterior con respecto a las fugas de datos y la partición de intercambio aún se aplica.
Si está realmente paranoico, puede usar un método, luego reiniciar en algún medio de instalación o entorno de recuperación a través de la red (la mayoría de los proveedores de alojamiento los tienen) y hacer el segundo método.