저는 소프트웨어가 로드되어 평가를 위해 잠재 고객에게 전송되는 시스템 풀을 관리하며, 종종 드라이브에 민감한 정보가 저장됩니다. 다시 배송하기 전에 일반적으로 표준 지우기를 실행하여 드라이브를 청소하는 것을 선호합니다. 대부분은 DBAN에 익숙하므로 내 시스템에서 작동하는지 확인하려고 노력합니다. 불행하게도 이것은 내가 보통 RAID 드라이버 지옥에 빠져서 내 시스템과 함께 제공되는 버전이 지원되는지 확인하려고 노력하고 있음을 의미합니다. 3ware와 LSI 등 다양한 종류가 있습니다.
결과적으로 일부에서는 DBAN 1.0.7을, 다른 일부에서는 베타 버전 2.0을, 일부 최신 SSD 기반에서는 2.2.6을 사용하고 있습니다. 이제 IBM x3550 M3(1064/1068)의 LSI 컨트롤러를 사용하면 전혀 마음에 들지 않습니다.
탈출구가 있나요? DBAN으로 루트를 구축하고 드라이버를 하나로 합치려고 합니까? 업데이트된 기타 무료 또는 상업용 도구입니다. 나는 다양한 기술적 숙련도를 가진 사람들에게 이 과정을 안내하려고 노력하고 있으므로 간단한 선택이 가능한 부팅 디스크가 더 좋습니다.
답변1
이제 우리는 드라이브를 지우기 위해 기계적 파괴를 사용하지만 드라이브를 재사용할 필요는 없습니다.
대상으로 삼을 특정 보안/감사 표준이 없다면 Linux 부팅 CD를 사용하고 드라이브에 /dev/random을 쓰기만 하면 더 큰 성공을 거둘 수 있습니다.
또 다른 옵션은 (응용 프로그램에 따라) 파일 시스템 수준에서 드라이브를 암호화하고 고객이 볼륨 키를 넘겨줄 때 볼륨 키를 변경하도록 하는 것입니다.
답변2
우리는 또한 DBAN을 사용합니다. 레이드 드라이버는 잊어버리세요. Dell 서버의 경우 RAID를 분리하고 각 물리적 디스크를 자체 RAID 0(RAID 0당 디스크 1개)에 할당했습니다. DBAN은 각 디스크를 찾아 모두 지웠습니다. 다른(아마도 가장 좋은) 옵션은 디스크 없이 장치를 귀하에게 돌려보내고 고객이 자신의 표준에 따라 장치를 폐기하도록 하는 것입니다. 이를 통해 귀하는 어떠한 책임도 지지 않게 됩니다.
편집: 질문을 다시 읽었으며 이것이 평가용이라는 것을 알았습니다. 고객이 데모용이라는 점을 이해하지 못하는 한 더 저렴한 니어라인 SAS나 SATA 드라이브를 사용하여 비용을 절감할 수도 있습니다.
답변3
DBAN 1.07/2.2.6에서도 비슷한 문제가 있었습니다. 여유 시간이 있어서 buildroot 2012.05 + disknukem의 i686 및 x86_64 일반 버전을 굴렸습니다(github의 Paolo Iannelli가 dwipe의 추가 개발). 또한 sg3_utils, sdparm을 넣고 lsiutil 1.63 소스 코드도 포함시켰습니다(예를 들어 RAID 볼륨에서 쓰기 캐시를 활성화하려는 경우). 64비트 버전은 다음에서 사용할 수 있습니다.http://www.cs.helsinki.fi/u/mcrantan/dban/dwipe-bzImage-x86_64최소한 Cisco B 시리즈 블레이드 및 qemu에서 작동합니다.
오래된 주제에 답변해서 죄송합니다(때때로 눈살을 찌푸린다고 들었습니다).