Уничтожение данных по живому серверу
http://www.storagesearch.com/disklabs-art3-floods.html
Не пытайтесь восстановить данные сами. Это нанесет больше ущерба Вашим данным и делает более трудным восстановиться, когда это в конечном счете доберется до специалиста по восстановлению данных.
Когда жесткие диски промокают, 'головы' могут застрять к дискам. Когда жесткий диск включается в этом состоянии, диск пытается вращаться, и головы буквально сорваны, нанеся ущерб дискам - место, где все данные хранятся. 2 - НЕ СУШИТЬ В СТИРАЛЬНОЙ МАШИНЕ жесткий диск. Хотя это может казаться парадоксальным - это будет почти всегда уничтожать диск жесткого диска, таким образом делающего Ваши невосполнимые данные.
Когда жесткие диски промокают, затем иссякают, существует почти всегда остаток загрязнителя, оставленного на дисках и головах. Любой остаток (включая кусок пыли), вызывает физическую неисправность дисков жесткого диска и теряет больше данных. 3 - ДЕЙСТВИТЕЛЬНО сохраняют жесткий диск ВЛАЖНЫМ. Идеально, сохраните жесткий диск в изолированном контейнере для хранения жесткого диска влажным. Это останавливает разъедание жесткого диска и позволяет техническому штату в компании по восстановлению чистить и сушить диски правильно с минимальным повреждением поверхностей диска.
Обычно, Восстановление данных Disklabs взимает премию за поврежденные жесткие диски воды, однако, эта дополнительная плата за очистку и сушку из жесткого диска была waivered для жертв последних событий лавинной рассылки.
If for some reason you want to shred the ENTIRE disk instead of just the sensitive data while the system is running, the only way you will be able to do this for sure is by creating a tmpfs (or other ramdisk) mount, copying the core utilities to it, then using pivot_root to move the root filesystem to the ramdisk, then unmounting the partition to shred it as per Womble's answer here. Actually doing this is a challenge, I tried once to see if it's possible, and was able to get just about everything but init working from the ramdisk, but had trouble getting init to move its control pipe (/dev/initctl) so I could unmount the partition.
Alternatively, based on this answer you can try shutting everything that might try to write a log file down, kill everything else not necessary, use lsof to find processes with open files and kill them, then try shredding the partition. If you're lucky the process will complete before the kernel discovers the filesystem is corrupt and panics. If you're not, the kernel will panic, shred will stop, and the system will definitely be unbootable with no way to finish shredding.
Otherwise, if you just need to shred the data, then I think you can be reasonably sure of doing so if the journal is set to data=ordered or writeback per shred's manpage, then shred the existing datafiles (if it's not set to a supported mode, it looks like changing it requires a reboot). To shred the unallocated space where data files may have once existed, use dd to fill the drive with large files, then shred those as well. Note that this option may leave various bits of metadata (directory entries with filenames, ownership, filesizes, etc) intact. The dd process will need to be run as root in order to guarantee it fills the drive since (by default) space is reserved for root's use that can't be filled by a regular user. You may want to stop logging (or log to a separate partition or tmpfs) during this since problems will arise once the drive is completely full.
shred и srm - две команды, которые можно использовать для безопасного удаления данных. Прочтите их справочные страницы для получения дополнительной информации.
Secure and Safe: Get secure and safe hard discs that encrypt the data.
Then instruct the disc to destroy the cryptographic key and make a new one.
Millisecond safe delete.
This is a standard option on most SAS discs these days.