왜 리눅스 시스템은 때때로 데이터를 복구 할 수 있습니까?

Linux 기반 컴퓨터 또는 Linux Live CD를 사용하여 Windows가 실행할 수없는 데이터를 복구 할 수있는 이유는 무엇입니까??

오늘의 질문 및 답변 세션은 Q & A 웹 사이트의 커뮤니티 중심 그룹 인 Stack Exchange의 하위 부문 인 수퍼 유저의 도움으로 이루어졌습니다..

질문

수퍼 유저 Philip Allgaier는 왜 Windows에서 복구 할 수없는 것으로보고 된 Linux Live CD로 데이터를 복구 할 수 있었는지 알고 싶어합니다.

배경: 올해 초 나는 Windows가 더 이상 인식 할 수있는 SSD 드라이브에 문제가있었습니다. 그러나 결국에는 부팅 가능한 Parted Magic 2012-10-10이 트릭을했습니다. 이 해결 된 스레드를 참조하십시오. 그 순간부터 나와 함께 붙어있는 한 가지 질문 ...

의문: 나는 리눅스가 일반적으로 좀 더 기술적이며 원시적 인 것을 알고 있지만 누군가가 리눅스 시스템 (또는 실제로 우분투가 트릭을하지 않았기 때문에 특정 시스템 만)이 여전히 절반의 액세스 / 통신이 가능한 이유를 대략적으로 설명 할 수있다 - Windows가 아닌 경우 손상된 장치?

그들은 뭔가 잠재적 인 지표를 무시하고 있는가??
어떤 구체적인 이유가 있습니까??
제한된 시간 동안 만이 특정 환경이 응답하도록 SSD를 얻을 수 있었다는 것이 행운 이었습니까??

확실히 운이 좋았을 지 모르지만, 몇 가지 요인 이상으로 작용할 가능성이 있습니다. 조사하자..

대답

수퍼 유저 기고가 아이케 (Eike)는 행운을 넘어 데이터 저장 능력에 대한 잠재적 인 설명을 제공합니다.

대개 이것은 정확히 무엇에 액세스하고 있는지, 정확하게 어떻게 장치가 실패하고 있는지에 달려 있습니다. 예를 들어 문제의 SSD가 섹터 5를 검색 할 수없고 어떤 섹터 5가 읽히 자마자 실속하기 시작하면 차이는 단순히 다른 시스템이 새 디스크를 인식하면 자동으로 액세스하는 다른 시스템이 원인 일 수 있습니다.

Windows가 새 디스크를 감지하면 파티션 테이블을 읽고 자동으로 읽는 방법을 알고있는 파일 시스템을 엽니 다. 이 "마운팅"프로세스 중에 읽히는 구조 / 블록 중 하나라도 결함있는 SSD가 작동하지 않으면 특정 Linux 배포판과의 차이는 문제의 모든 파티션을 자동으로 마운트하지 않을 수도 있고, 마운트 할 때 단순히 섹터의 다른 하위 집합을 읽습니다 (Linux의 NTFS 구현은 Windows의 구현과 매우 다릅니다. 디스크상의 형식은 동일하지만 읽을 필요가 있다고 생각하는 구조에 달려 있습니다). Windows는 MFT의 2 차 사본을 읽을 수도 있고, 일부 데이터를 미리 캐싱 할 수도 있으며, 그 차이가있을 수 있습니다. 우분투는 유사한 보트에 있습니다. 상자에서 벗어나지 않고 탐색 한 파일 시스템을 마운트하려고 시도합니다 새롭게 발견 된 미디어에서 자동으로 검색하므로 자동으로 작업하는 것과는 대조적으로 사용자가 명시 적으로 요청한 작업 만 수행하므로 복구 작업에 특화된 배포가 더 나은 방법입니다..

물론, 당신은 단순히 행운을 얻었을 수도 있습니다. 나는 SSD의 실패 모드에 대해 충분히 알지 못한다..

리눅스는 일반적으로 어떤 것이 잘못되었다는 지표를 무시하지 않습니다. Windows와 마찬가지로 동일한 SCSI 오류를 SATA 칩셋에서 받게됩니다. 커널 로그를 보면 잘못된 디스크에 많은 오류 메시지가 표시됩니다. 어떤 프로그램이 디스크에 실제로 액세스하는지에 따라 다음에 어떤 일이 일어날 것인가에 달려 있습니다. 복구를 목표로하는 소프트웨어 인 경우 동일한 섹터를 제한된 횟수만큼 다시 읽으려고 시도 할 수 있으며 건너 뛸 수 있습니다. 일반적으로 최선의 방법은 최대한 많은 섹터를 깨끗하게 읽는 방법으로 드라이브의 이미지를 얻는 것입니다. 그런 다음 이미지에서 데이터를 복구하려고 시도하십시오. 드라이브에서 직접 분석하는 것은 일반적으로 상태가 나빠질 수 있고 단지 한 번 읽을 수 있었기 때문에 좋지 않은 아이디어입니다. 다시는 읽을 수있는 것은 아닙니다. .)

동료 기고 가인 AthonSfere는 다음과 같은 일들을 제안합니다 :

그 중 많은 부분이 환경이 파일 시스템을 처리하는 방법이며, ACL 또는 하드 드라이브.

Windows는 ACL 및 악성 또는 비어있는 것으로 표시된 섹터에 따라 자체적으로 할 수있는 모든 작업을 수행합니다. 따라서 Windows 및 Windows MBR에서 생성되고 유지 관리되는 NTFS 또는 Fat 파티션은 Windows에서 Windows로 표시된대로 Windows에서 처리됩니다..

또한 드라이브가 고장 나면 더 많이 사용하며 큰 문제가 발생할 가능성이 높아지고 환경이 손상됩니다. 그런 다음 OS가 처리하는 방식, Windows가 BSOD 또는 재부팅하는 경우 Windows 부팅 프로세스에서 MBR 메시지가 누락되고 파일 메시지 (누락되거나 손상된 NTDLR.dll)가 누락되어 이러한 잘못된 파일이 필요하기 때문에 중지합니다.

라이브 디스크를 사용할 때, 당신은 이것에 의존하지 않습니다. 디스크를 부팅하면 불량 MBR이 무시됩니다. NTDLR.dll을 손상시킨 불량 섹터는 필요하지 않습니다. 모든 것이 디스크에 있습니다. 그런 다음 읽기를 시도 할 수 있습니다. '빈'섹터 또는 불량 비트가 발견되면 해당 환경이 처리하지만 프로그래밍 된 것입니다. 우분투는 오히려 정상적인 OS 동작을 유지하고 일어날 가능성이 높은 작업을 계속 진행합니다. 섹터가 비어 있거나 다른 작업을 수행합니다. 해당 분야가 나쁘거나, 멀리 있거나, 다시 읽지 않거나, 문제가 발생할 것입니다..

그러나 복구 플랫폼은 모든 데이터를 읽으려고합니다. 파일 표시자는 파일이 0,5,13 ...에 있어야한다고 말합니다. 파일 시스템이 13을보고하는 경우, 공백 헤더를 무시하고 어쨌든 파일을 읽거나 가능한 한 나쁜 섹터를 읽고 복구하려고 시도합니다.

또한 Windows는 타사 응용 프로그램으로이 작업을 많이 수행 할 수 있으므로 Recuva는 이러한 "누락 된"파일을 많이 찾을 수 있습니다. 그러나 디스크에 다시 쓰고 참 영구 손실을 초래할 수있는 환경에 있기를 원하지는 않습니다..

나는 이것을 단순화하고 약간의 해석을 추가했으나, 여러분이 묻는 것에 대해 공란을 채워야한다..

설명에 추가 할 것이 있습니까? 의견에서 소리가 나지. 다른 기술에 정통한 Stack Exchange 사용자의 답변을 더 읽고 싶습니까? 전체 토론 스레드를 여기에서 확인하십시오..

http://superuser.com/questions/586666/why-can-linux-systems-sometime-recover-data-windows-cant-any-concrete-reasons