드라이브를 판매할 때마다 라이브 환경의 조각화를 통해 한 번에 드라이브를 초기화합니다.
sudo shred -vzn 0 /dev/sdX
다시 확인하기 전까지는 설치되지 않았습니다. 이것이 드라이브를 안전하게 지우는 가장 빠른 방법입니다. 이제 이것이 SSD에 좋지 않다고 들었습니다. SSD만큼 빠르거나 더 빠른 SSD를 안전하게 지울 수 있는 방법이 있습니까?
이론적인 관점에서 볼 때, 복구가 불가능하도록 전체 볼륨을 커버해야 한다는 것을 이해합니다. 그래서 SSD의 스트레스를 줄이는 방법을 모르겠습니다. 한 번의 패스로 SSD의 수명이 전혀 단축되지 않는다고 들었습니다.
그렇게 빨리 될까요 cat /dev/zero > /dev/sdX?
여기서는 민감한 데이터를 다루지 않으며, 지식이 풍부한 사람이 데이터를 복구하기 위해 많은 노력을 기울이는 것으로부터 드라이브를 보호할 필요도 없습니다. 나에게 필요한 것은 SSD의 수명을 줄이지 않는 속도다.
편집자: 예이것SSD는 HDD와 동일한 원리로 작동합니까?
dd if=/dev/urandom of=/dev/sdc bs=1M count=2
답변1
SSD에 블록 쓰기확실히오래된 블록을 덮어씁니다. 최근 SSD는 모두 '웨어 레벨링(Wear Leveling)'이라는 기술을 사용하기 때문이다.
SSD에 블록을 쓰려면 새 데이터를 쓰기 전에 블록을 지워야 합니다. 그러나 지우기는 제한된 횟수만 수행할 수 있는 작업입니다. 지우기를 수행할 때마다 블록을 더 이상 제대로 지울 수 없을 때까지 하드웨어가 "약해집니다".
따라서 동일한 블록을 지우고 덮어쓰는 대신 웨어 레벨링을 통해 SSD는 사용되지 않은 다른 블록을 선택하고 해당 블록에 기록하며 이전 블록의 데이터는 그대로 유지됩니다.
이전 블록의 데이터가 제자리에 있으면 여전히 읽을 수 있다는 의미입니다.
그래서어느cp파일( , dd, 등) 을 "덮어쓰기" 위해 사용할 수 있는 명령에는 cat모두 shred다음과 같은 약점이 있습니다. 실제로 파일을 전혀 덮어쓰지 않고 대신 0, 임의의 데이터 또는 기타 항목을 파일에 씁니다.새로운조각.
따라서 하드 드라이브와 달리 이는 데이터가 사라지고 다른 사람이 읽을 수 없도록 하는 좋은 방법이 아닙니다.
모든 쓰기 작업은 SSD의 제한된 쓰기 횟수를 소진하여 SSD의 수명을 단축시키기 때문에 이러한 명령은 모두 SSD에 "나쁜" 명령입니다. 그리고 shred파일을 반복적으로 덮어쓰기 때문에 특히 나쁩니다. 하드 드라이브에서 이는 다음과 같은 목적을 가지고 있습니다. 읽기-쓰기 헤드는 완벽하게 중앙에 위치하지 않으므로 여러 번 덮어쓰면 트랙 가장자리에 다른 사용자가 사용할 수 있는 잔여 자기 데이터가 없도록 보장됩니다(또는 보장하려고 시도합니다). 데이터를 재구성할 수 있는 지식이 있는 사람.
에 관해서는블록 폐기, 이는 호출됩니다.퍼스트림, ATAPI 트림 비트를 사용하여 블록이 더 이상 필요하지 않음을 드라이브에 알립니다. 자세한 내용은 다음에서 확인할 수 있습니다.ACS-4 사양.
그러나 이는 안전하지 않습니다. SSD에 이 블록을 비어 있고 재사용 가능한 블록 목록에 넣으라고 지시할 뿐입니다. SSD에는 실제로 블록을 즉시 삭제할 수 있는 옵션이 있고, 유휴 상태일 때 또는 블록이 다음에 기록되기 전에도 삭제할 수 있습니다. 따라서 이는 데이터가 사라지는 것을 보장하는 안전한 방법이 아닙니다.
TRIM이 도입된 이유는 SSD가 파일 시스템이 여전히 데이터가 포함된 블록을 사용하고 있는지 여부를 확인할 수 없기 때문입니다. 즉, 파일 시스템이 사용을 중지하더라도 웨어 레벨링에 사용되는 풀에 추가할 수 없다는 의미입니다.TRIM은 블록을 지우는 안전한 방법이 아닙니다..
댓글에서도 언급했듯이 안전하게 제거하는 방법이 있습니다.충분히SSD. 그러나 단지 개별 파일을 안전하게 삭제하려는 경우에는 원하는 것이 아닐 수도 있습니다.
그렇다면 귀하의 사용 사례에 적합한 솔루션은 무엇입니까? 그것이 사실이라면
여기서는 민감한 데이터를 다루지 않으며, 데이터를 복구하기 위해 많은 노력을 기울이는 지식이 풍부한 사람으로부터 드라이브를 보호할 필요도 없습니다.
그런 다음 을 사용할 수 있습니다 rm. 실제로 파일 시스템에서 삭제된 파일을 복구하려면 많은 지식과 노력이 필요합니다. ext4특히 해당 파일 시스템에 동시에 더 많은 쓰기가 발생한 경우 더욱 그렇습니다. 가능한 일이지만 아무나 할 수 있는 일은 아닙니다. 물론 이것은 가장 빠른 변형입니다.
차선책은 blkdiscardTRIM 지원 SSD에서만 작동하지만 최신 SSD의 경우에도 마찬가지입니다. 위에서 언급했듯이 이는 안전하지 않지만 이제 SSD에 직접 액세스할 수 있는 사용자에 대한 기준이 높아졌습니다. 특별한 하드웨어 없이는 누구든지 이 작업을 수행할 수 없습니다.
어떤 방식으로든 파일을 덮어쓰는 것은 여전히 최악입니다. 재구축 기준은 위와 동일하지만 그렇게 하면 SSD의 수명이 단축되고 어떤 명령을 사용하든 더 오랜 시간이 걸립니다.
답변2
이것이 드라이브를 안전하게 지우는 가장 빠른 방법입니다.
SSD의 경우 그렇지 않습니다.
blkdiscard /dev/device귀하의 사용 사례에 비해 수십 배 빠르고 안전합니다.
cat /dev/zero > /dev/sdX가 그렇게 빠를까요?
표면적으로 이 두 명령은 똑같이 빨라야 합니다.
나에게 필요한 것은 SSD의 수명을 줄이지 않는 속도다.
SSD에 0을 쓰는 것만으로도 SSD의 수명이 단축됩니다. 0은 여전히 데이터입니다.
답변3
완벽하게 지원되는 경우 hdparm과 함께 보안 지우기를 사용하는 것이 좋습니다.
https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
SSD를 지우는 단계별 지침은 다음과 같습니다.
답변4
편집: HDD와 마찬가지로 SSD에서도 작동합니까?
dd if=/dev/urandom of=/dev/sdc bs=1M count=2
물론 이는 파티션 테이블과 첫 번째 파티션의 시작 부분(보통 1MB에서 시작)을 포함할 수 있는 드라이브의 처음 2MB를 기록함으로써 수행됩니다.
대부분의 파일과 다른 파티션의 전체 파일 시스템은 그대로 남아 있으며 일반 컴퓨터와 일반 운영 체제에서 읽을 수 있습니다. 이를 찾는 것은 소프트웨어만 있으면 됩니다.
또한 GPT는 드라이브 끝(덮어쓰지 않음)에 파티션 테이블의 백업 복사본을 저장하며, 일부 파일 시스템에는 기본 데이터 구조의 백업 복사본이 있으므로 첫 번째 파일 시스템도 사용할 수 있습니다.
의견에서 논의한 것처럼 이는 모든 드라이브에 똑같이 나쁜 솔루션입니다.답변당신이 링크했습니다.
(물론 SSD에서는 이전 데이터 블록을 실제로 덮어쓰거나 삭제하지도 않을 수 있으므로 적절한 도구/소프트웨어를 사용하여 복구할 수 있으므로 SSD에서는 유용하지 않습니다. 그러나 이는 대부분의 흥미로운 데이터를 보유하는 것과는 다릅니다. 여전히 일반적인 방법으로 읽을 수 있는 것에 비하면 큰 문제는 아닙니다.)
파티션 테이블과 파일 시스템을 지우는 것만으로도 만족한다면 일반 파티션 도구를 사용하여 빈 파티션 테이블을 새로 만들고 새 파티션을 생성하여 모든 파티션의 모든 파일 시스템을 지우는 것이 좋습니다. 모든 파일 시스템을 지우는 테이블입니다. 그것들은 위에 있습니다. (SSD에 대한 주의 사항은 여전히 적용되지만, 적어도 복구하려면 디버그 스타일의 드라이브 액세스에 대한 전문 지식이 필요합니다.)