DDRescue를 이용하여 마이그레이션이 불가능할 정도로 손상된 HDD/SSD 복원

최근 가족이 운영하는 치과병원에서 치아 X-Ray 촬영 장비에 연결되어 있던 약 7년 정도 된 컴퓨터가 고장이 나서 복원을 시도했다. 윈도우즈 운영체제 차원에서 계속하여 하드디스크가 손상되었으니 백업을 해야한다는 메세지가 표시되는 현상이었는데, 아마도 S.M.A.R.T. 검사 통과에 실패한 것으로 보였고 경험적으로 해당 검사에 통과하지 못한다는 것은 조만간 하드디스크 데이터에 접근 조차 불가능해질 수 있는 매우 안좋은 시그널이었기에 신속하게 집으로 가져왔다.

컴퓨터를 열어보니 예상과는 달리(?) HDD가 아닌 SSD가 달려있었는데, 사용하던 데스크탑에서 SSD 가 부족하여 새로운 SSD를 구매 후 운영체제 까지 통째로 영혼까지 복제 해버리는 마이그레이션(migration) 작업을 한두번 해본게 아니었기 때문에 쿠팡에서 WD의 보급형 SSD를 주문하여 마이그레이션 툴을 작동시키면 금방 고칠 것이라 생각했다.

그런데 왠걸, Macrium reflect / Acronis / Clonezilla 등 하드디스크 복제를 위한 마이그레이션 프로그램 중 가장 유명한 3종 세트를 다 동원해봐도 진행률 13% 수준에서 지속적으로 복제에 실패 했다는 메세지를 표시하며 진행이 안되었다. Macrium을 기준으로 오류메세지는 아래와 같았다.

Clone failed – Error 0 – Read failed – 23 – Data error (cyclic redundancy check)
Error Code 23 – Data error (cyclic redundancy check)
Macrium reflect

그래서, 이 글은 Macrium reflect, Acronis true image, Clonezilla 어떤 마이그레이션 프로그램으로도 복제하지 못하던 심각하게 손상된 SSD를 오픈소스 툴 GNU DDRescue를 통해서 복원해낸 이야기이다.

하드디스크 드라이브(HDD)와 솔리드 스테이트 드라이브(SSD)는 컴퓨터 시스템의 중요한 데이터 저장 장치로 사용되지만, 이들의 수명은 무한하지 않다.

HDD의 유한한 수명

기계적 마모: HDD는 회전하는 디스크, 이동하는 읽기/쓰기 헤드 같은 기계적 부품을 사용하여 데이터를 저장한다. 이런 부품은 지속적인 사용으로 인해 마모되고, 결국 고장날 수 있다.
물리적 손상 가능성: HDD는 충격이나 떨어뜨림과 같은 물리적인 힘에 취약하다. 이런 충격에 의해 내부 부품이 손상되면 드라이브가 작동을 멈출 수 있다.
열적 스트레스: 장시간 사용으로 인해 발생하는 열은 HDD의 부품을 약화시키고 수명을 단축시킬 수 있다.

SSD의 유한한 수명

셀 마모: SSD는 NAND 플래시 메모리를 사용해 데이터를 저장한다. 이 NAND 메모리 셀은 현재 기술에서 제한된 횟수의 쓰기/지우기 사이클만 견딜 수 있으며, 이 한계에 도달하면 더 이상 사용할 수 없게 된다.
컨트롤러의 수명: SSD의 컨트롤러는 데이터의 읽기 및 쓰기 작업을 관리한다. 이 컨트롤러도 일정시간이 지나면 열적/전자적 손상에 따라 결국 고장날 수 있다.

결국 HDD/SSD 든 유한한 수명을 가지고 있고, 언젠가는 고장이 난다는 말인데 이번에 고장난 컴퓨터와 같이 쓰기 작업이 빈번한 컴퓨터에서 사용되는 SSD의 경우 그 수명은 생각보다도 훨씬 짧다. 그나마 읽기라도 가능한 상태라면 새로운 SSD를 구매하여 복제를 하면 되겠으나, 이번과 같이 정상적인 읽기 조차 어려운 상황이라면 조금 다른 접근 방법이 필요하다.

DDRescue에 관하여

DDrescue (GNU ddrescue)는 데이터 복구 도구로, 손상되거나 오류가 발생한 드라이브에서 데이터를 복구하는 데 사용된다. 이 프로그램의 핵심 알고리즘은 다음과 같이 정교하게 작동한다. chkdsk 등으로도 복구가 안되는 하드디스크들에 대해서되 최선의 결과를 보장한다.

선형 복구: DDrescue는 처음에 디스크의 데이터를 선형적으로 읽는다. 즉, 시작 부분부터 순서대로 데이터를 읽어 들인다. 이 단계에서는 오류가 발생하지 않은 영역을 대상 디스크로 빠르게 복사한다.
오류 처리: 오류가 발생하는 영역을 만나면, DDrescue는 그 위치를 기록하고 건너뛴 후 다음 영역의 복사를 계속한다. 이렇게 함으로써, 복구 과정 자체가 디스크에 추가 손상의 원인으로 작용하는 것을 최소화하고 디스크의 오류가 적은 부분부터 데이터를 복구할 수 있다.
역방향 접근: 초기 스캔이 완료된 후, DDrescue는 오류가 발생한 영역을 역방향으로 접근하여 다시 시도한다. 이는 더 많은 데이터를 복구할 수 있는 기회를 제공한다.
분할 및 정복: 오류가 발생한 영역에 대해서는, DDrescue는 ‘분할 및 정복’ 알고리즘을 사용한다. 오류가 발생한 영역을 더 작은 부분으로 나누고, 각 부분을 개별적으로 처리하여 가능한 많은 데이터를 복구하려고 시도한다.
재시도: DDrescue는 설정에 따라 오류가 발생한 영역을 여러 번 재시도할 수 있다. 이 과정에서 더 많은 데이터가 복구될 수 있다.
로그 파일 사용: 복구 과정에서 DDrescue는 로그 파일을 사용하여 진행 상황을 기록한다. 이 로그 파일 덕분에 복구 과정을 중단했다가 나중에 다시 시작할 때 처음부터 다시 시작하는게 아니라 이전 작업을 이어갈 수 있다.

결국 DDrescue의 이러한 정교한 알고리즘은 특히 물리적으로 손상된 드라이브 또는 불안정한 드라이브에서 새로운 디스크 드라이브로 데이터를 복제/복구하는 데 유용하다.

DDRescue 사용 방법

1단계: 도구 준비

DDRescue: 리눅스 기반의 데이터 복구 도구
새 SSD 또는 다른 저장 장치: 손상된 디스크에서 복구된 데이터를 저장할 장치(원본 손상디스크와 같거나 더 큰 용량 권장)
부팅 가능한 리눅스 라이브 CD 또는 USB: 손상된 디스크에 저장된 운영체제를 통해 부팅 할 경우 해당 운영체제가 디스크를 사용하면서 손상된 디스크의 상태를 악화 시킬 수 있기 때문에, 시스템에 직접적인 영향을 주지 않고 리눅스 환경을 사용할 수 있도록 하는 부팅 가능한 리눅스 미디어가 필요하다.

2단계: 리눅스 라이브 환경 구축

리눅스 라이브 CD나 USB를 사용하여 컴퓨터를 부팅합니다.(부팅가능한 리눅스를 구축하는 방법은 검색엔진을 활용하면 쉽게 얻을 수 있으므로 패스)
필요한 경우, 인터넷을 통해 DDRescue를 설치합니다. 대부분의 리눅스 배포판에서는 패키지 관리자를 통해 쉽게 설치할 수 있다.

Ubuntu, Debian 및 Linux Mint에 ddrescue를 설치하려면
$ sudo apt install gddrescue

Fedora, CentOS, AlmaLinux 및 Red Hat에 ddrescue를 설치하려면:
$ sudo dnf install ddrescue

Arch Linux 및 Manjaro에 ddrescue를 설치하려면:
$ sudo pacman -S ddrescue

3단계: 손상된 SSD와 신규 SSD 연결

부팅 이전에 손상된 SSD와 신규 SSD를 컴퓨터에 연결한다.
드라이브 식별자 확인 : 리눅스에서는 일반적으로 lsblk 명령어를 통해 드라이브를 확인할 수 있습니다.

4단계: 복구 프로세스 실행

터미널을 열고 DDRescue 명령어를 실행합니다. 기본 형식은 다음과 같다.
sudo ddrescue -d -r3 /dev/sdx /dev/sdy /path/to/logfile.log
여기서 /dev/sdx는 손상된 드라이브, (lsblk 명령어로 확인)
/dev/sdy는 데이터를 복구할 대상 드라이브, (lsblk 명령어로 확인)
/path/to/logfile.log는 로그 파일의 경로이다.
-r3 옵션은 DDRescue가 오류를 3번까지 재시도하도록 지시합니다. 이는 복구 가능성을 높이기 위함이다. 3보다 높은 숫자를 입력하면 더 많은 횟수를 시도하지만, 어차피 3회를 넘어서는 횟수를 시도한다고 복구확률이 높아지지 않을 뿐더러 숫자를 올릴 수록 복구를 완료하는데 필요한 시간이 기하급수적으로 증가하기 때문에 3을 추천한다.

5단계: 복구 상황 모니터링

DDRescue는 복구 진행 상황을 실시간으로 보여준다. 오류가 많은 영역에서는 속도가 느려질 수 있다.

6단계: 복구 완료 후 확인

복구 프로세스가 완료되면, 손상된 SSD를 대신하여 복구된 SSD 를 해당 위치에 장착 이후 부팅을 시도하거나, 혹은 부팅 드라이브가 아니었다면 복구된 신규 SSD 파일시스템에 접근하여 복구된 데이터를 확인한다.

결론

이 방법을 통해 나는 어떠한 SSD 마이그레이션 프로그램으로도 복제가 불가능하던 SSD을 복제와 함께 데이터 역시 대부분 복원하는 것에 성공하였다. (심지어 복구된 SSD로 부팅 결과 아무런 문제도 없었다는 듯이 윈도우즈 운영체제가 동작) 다만 하드디스크의 손상 정도와 상황에 따라 복원의 수준이 달라질 수 있다보니 모두가 나와 같이 성공한다고 장담하긴 어렵다.

DDRescue는 무료 소프트웨어이지만, 정교하게 작동하고 충분히 시도해볼 가치가 있다. 특히 SSD가 손상되어 새로운 SSD로의 마이그레이션과 함께 데이터 복원도 안전하게 해내고 싶다면. (리눅스를 다룰 수 있는 기본적인 지식은 필요하다. 이게 어렵다면, 전문가의 도움을 받자.)

AWS Elastic Beanstalk 413 Request Entity Too Large 오류 해결

문제의 원인

Elastic Beanstalk 를 이용해서 웹 서비스를 Deploy 할 경우 어플리케이션의 Reverse Proxy로 사용되는 Nginx의 설정 때문이다. Nginx의 설정 값 중 client_max_body_size를 이용하면 client가 너무 큰 사이즈의 request를 보내지 못 하도록 제한을 걸 수 있다. 이 설정은 request의 Content-Length 헤더값이 client_max_body_size에 설정된 값을 넘을 수 없도록 제한한다.(악의적인 대용량 파일 업로드 등을 방지하는데 사용)

다만 이 client_max_body_size 의 기본 값이 1MB 정도로 너무 낮게 설정되어 있기 때문에, 1MB를 초과하는 파일을 POST로 업로드 하는 일반적인 상황에서도 에러메세지가 표시되며 요청이 실패하는 경우가 발생 한다.

해결 방법

Elastic Beanstalk 환경이 아니라면, Nginx 설정(nginx.conf)파일을 직접 수정하는게 가장 빠른 해결책 이겠지만, Elastic Beanstalk 을 사용하여 배포된 환경에서 해당 인스턴스에 직접 접속하여 Nginx 설정 파일을 직접 수정하는 것은 좋은 생각이 아니다. 직접 Nginx파일을 수정하면 오토스케일링 상황에서 새로 생성된 인스턴스에서는 여전히 동일한 이슈가 발생하거나 해당 어플리케이션을 새로운 환경에 배포 했을 때에도 동일한 문제가 재발 하여 환경의 강건성(Robustness)을 떨어뜨리는 요인이 되기 때문이다. 어플리케이션 코드 이외의 인프라에 신경을 쓰지 않아도 되도록 만들어주는 Elastic Beanstalk의 장점을 십분 살리기 위해서는 Elastic Beanstalk 에 업로드 되는 어플리케이션 패키지 내에서 해당 이슈를 해결 할 수 있도록 구성하여야 한다.

AWS Elastic Beanstalk 공식 문서 중 Extending Elastic Beanstalk Linux platforms 를 참고 하면 배포되는 환경의 Nginx 설정을 수정하는 방법에 대해 정확히 서술되어 있는데 어플리케이션 루트(아래 구조 예시에선 ~/workspace/my-app/)에서 아래와 같은 경로에 Nginx 설정 파일을 추가하면 해당 설정을 배포 환경의 Nginx가 포함하게 된다.

~/workspace/my-app/
|-- .platform
|   `-- nginx
|       `-- conf.d
|           `-- myconf.conf
`-- other source files

즉 위 구조에서는 myconf.conf의 내용으로(파일명은 상관 없음, 확장자는 .conf 이어야 함) 원하는 최대 용량을 아래와 같이 지정하고 어플리케이션을 다시 배포하면 해당 문제를 해결 할 수 있다.(0으로 값을 지정하면 무제한으로 설정됨)

client_max_body_size 50M;

부동산 거래 시 매도인의 하자담보책임에 대한 정확한 정리

거의 6개월에 가까운 고생 끝에 결국 어느정도 마음에 들고 조건에도 맞는 매물을 찾아 계약을 진행하게 되었다. 모든 재화를 구매할 때 우리는 그 재화가 판매되는 가격에 상응하는 가치를 가지고 있는지, 그리고 해당 재화에 결함이나 특별한 하자가 없는지 판단하고 구매를 하는 것이 일반적일 것인데 주택의 경우 우리가 살면서 구매하는 재화 중 가장 비싼 축에 해당하기 때문에 이러한 두가지 과정을 더욱더 신중하게 진행 할 수 밖에 없다.

지난 6개월간 서울 전역을 임장하고 돌아다니면서 고생한 것은 사실 전자에 관한 것 이었고(예산, 거주 환경, 통근 등 다양한 제약조건 내에서 가격 대비 최고의 가치를 가진 아파트를 찾아내는 것) 막상 물건을 정하고 계약을 진행하려고 하니 후자와 관련된 것이 걱정이 되기 시작했다. 몇천만원 짜리 자동차를 살 때에도 인수 직전 물건에 문제가 없는지 꼼꼼히 살피는데, 아파트의 경우 그것에 비해 몇십배 비싼 재화 이면서도 자동차와 비교도 할 수 없을 정도로 많은 요소들(토지, 건물, 인테리어, 샷시, 배관, 보일러 등)이 하나의 재화를 구성하고 있는데 오죽 하겠는가.

신축 아파트의 경우 상대적으로 시설의 상태가 양호할 확률이 높고, 해당 아파트를 시공한 시공사가 일정기간 ‘하자보수’ 기간을 보장하기 때문에 크게 걱정할 것은 없지만 우리와 같이 준공 후 20년이 넘는 ‘구축아파트’를 매수 할 경우 세월의 풍파에 따라 시설물의 상태가 악화되어 있을 가능성이 높고 그러한 상황에서 매수한 아파트에 문제가 발생할 경우 이 문제에 대한 책임을 두고 매도인과 매수인사이에 분쟁이 발생할 가능성이 높아진다.

매도인의 ‘하자담보책임’

이러한 분쟁의 상황에 대비하여 대한민국 민법 제 580조에서는 매도인의 ‘하자담보책임’을 아래와 같이 규정하고 있다.

제580조(매도인의 하자담보책임) (1) 매매의 목적물에 하자가 있는 때에는 제575조 제1항의 규정을 준용한다. 그러나 매수인이 하자있는 것을 알았거나 과실로 인하여 이를 알지 못한 때에는 그러하지 아니하다.
제575조(제한물권있는 경우와 매도인의 담보책임) (1) 매매의 목적물이 지상권, 지역권, 전세권, 질권 또는 유치권의 목적이 된 경우에 매수인이 이를 알지 못한 때에는 이로 인하여 계약의 목적을 달성할 수 없는 경우에 한하여 매수인은 계약을 해제할 수 있다. 기타의 경우에는 손해배상만을 청구할 수 있다.
제582조(전2조의 권리행사기간) 전2조에 의한 권리는 매수인이 그 사실을 안 날로부터 6월내에 행사하여야 한다.
민법 제580조, 제575조 제1항, 제582조

즉, 매매의 목적물(아파트)에 하자가 존재하는 경우 매수인은 매도인에게 해당 하자에 대한 손해배상을 청구 할 수 있고 더 나아가 매매 계약을 해제 할 수 있다는 것이다. 다만, 위 조항은 무조건적으로 하자 발생 시 매도인에게 손해배상을 청구하거나 계약을 해제 할 수 있다는 조항은 아니며 일반적으로 아래와 같이 네개 조건을 충족해야 한다.

정당하게 성립된 매매 계약 이어야 함
매수인이 계약 시점에 해당 하자의 존재에 대해 알지 못했어야하며, 매수인의 과실로 알지 못한 경우는 인정되지 않음(즉, 매도인이 하자에 대해 계약시점에 미리 고지하고 매매한 경우는 해당하지 않으며 하자에 대해 충분히 확인이 가능하였으나 매수인측의 과실로 계약시점에 인지하지 못한 경우는 해당하지 않음)
매수인은 하자를 인지한 날로 부터 6개월 이내에만 손해배상 청구 혹은 계약해제를 요구 할 수 있음(즉, 계약 시점이 기준이 아니고 하자를 인지한 시점을 기준으로 6개월 이내임)
하자는 계약시점에도 존재하여야 함(판례 상, 계약 시점은 계약 체결일 뿐만이 아니라 계약의 최종 이행일인 잔금일 까지를 의미함. 잔금일 이후 매수인이 하자를 발견하게 되는 경우 매수인은 적어도 잔금일 이전에도 해당 하자가 존재함을 입증해야 함)

인터넷에 관련된 내용을 찾아보면 특히 3과 관련하여 잘못된 정보가 공유되고 있는 경우를 심심치 않게 목격 할 수 있는데 – 가령 잔금일로 부터 6개월내 발생한 하자는 모두 매도인의 책임이라는 둥 – 이는 위에서 언급한 민법 조항만 잘 읽어보아도 잘못된 내용임을 알 수 있으며 심지어 개업 공인중개사 분들도 잘못된 내용을 작성, 공유하여 많은 혼란을 초래하고 있으므로 반드시 유의가 필요하다.

하자 담보 책임과 관련한 계약서 상 특약 조항 관련

보통 노후한 아파트에서 발생하는 중대하자의 경우 누수, 균열 등으로 발생 할 경우 비용이 크게 발생될 뿐만 아니라 해당 문제를 해결하는 과정에서 이웃간에 불필요한 스트레스가 발생하는 경우가 많기 때문에 매도인과 매수인 모두 해당 문제에 대해 민감하게 반응하기 마련이고, 이로인해 보통은 매매 계약서 상 특약을 넣고 계약을 체결하는 경우가 많다.

하지만 이번 매매 계약을 진행하면서 여러 방면으로 공부하고 정리를 해본 결과 정답은 ‘어차피 법에서 정의하고 있는 내용으로, 관련된 내용에 대해서는 별도로 계약서에 기입하지 않는 것’이라고 결론 내렸다.

통상 특약사항에 기입되는 내용들이 ‘중대하자가 발생할 경우 잔금일 이전에는 매도인 책임 잔금일 이후에는 매수인 책임'(이 경우 매도인이 발견하기 어려운 중대하자에 대해 잔금일 까지도 숨길 경우 매수인에게 불리함) 이라던지 ‘중대하자가 발생할 경우 잔금일로 부터 6개월까지는 매도인이 손해를 배상한다.'(이 경우 매수인의 과실여부나 계약 시점 하자 존재 여부와 무관하게 매도인이 배상하여야 하므로 매도인에게 불리함) 등 매도인이나 매수인 일방에 유리한 쪽으로 공평하지 않게 기입되는 경우가 많고(아마 공인중개사들이 분쟁 발생 시 책임 회피용으로 넣는 경우도 많은 것으로 안다.) 이렇게 공평하지 않게 작성된 특약은 어차피 큰 분쟁이 발생 하였을 경우 법정 공방으로 이어질 가능성이 높기 때문이다.

어차피 법에서 정확히 정의하고 있는 사안이라면, 매도인과 매수인 사이에서 특약 내용과 관련하여 불필요한 논쟁을 발생시키기 보다는 아예 관련 조항을 빼버리고 분쟁 발생 시 법적인 판단을 받는 것이 더 현명한 방법이라고 판단하였다.

중대 하자를 대하는 매수인의 태도

결국, 하자 발생 시 매도인의 하자담보 책임과 관련하여 가장 까다로운 부분은 해당 하자가 ‘계약시점(판례에 따르면 계약체결일 뿐만이 아니라 계약의 이행 시점인 잔금일 까지)’부터 이미 존재 하는 하자이어야 한다는 것이다.

따라서, 이사한 바로 다음날 갑자기 누수 등 중대한 하자가 발생한다고 하여도 그 하자가 잔금일에도 존재한다는걸 입증하지 못한다면 매수인은 매도인에게 하자보증책임을 요구하기 어렵다.

이러한 상황에서는 결국 아래와 같이 잔금일 이전까지 꼼꼼하고 지속적으로 매수 대상 물건에 대한 하자를 점검하는 것이 매수인에게 가장 중요한 자세라고 생각한다.

매물 탐색 과정에서 첫 방문시 부터 집의 하자 유무에 대해 다방면으로 파악한다.(주요 하자 요소들에 대한 리스트를 미리 머리속에 담아두고 점검, 매도인 혹은 세입자와의 대화를 통해서 간접적으로 하자 유무 및 과거 히스토리 파악)
계약서 작성일에 매도인에게 하자 유무와 하자 발생 시 책임에 대한 질문을 하며 그 답변 사항에 대해 녹음(분쟁이 발생하여 소송전에 이르게 될 경우 최소한의 안전 장치 확보, 본인이 대화에 참여하면 녹음이 불법이 아님)
잔금일 잔금을 치르기전 주택의 최종 상태 확인하여 미리 고지되지 않은 하자 사항이 발견될 경우 매도인과 보상 협의
잔금일 이후 만약 하자가 발생할 경우, 즉시 해당 하자의 전문가와 객관적인 상담을 진행하고 계약 시점에도 존재하였을만한 하자로 판단될 경우 하자 발생 사실에 대해 매도인에게 내용증명 등을 통해 통보

결론 : ‘어차피 완벽한 보호장치는 없다.’

결국, 매수한 주택에서 하자가 발생하는 일은 실제로 존재 할 수 있고 구축 아파트라도 매우 비싼돈을 주고 구매해야하는 작금의 현실 속에서 하자가 발생 할 경우 보상 책임에 대해선 매도인과 매수인 사이에서 피곤한 책임 공방전으로 이어질 가능성이 높다. 어떠한 경우에도 매도인 혹은 매수인 한쪽을 일방적으로 보호 할 수 있는 수단이 존재한다고 볼 수 없고, 계약의 당사자인 매수자가 인터넷에 떠도는 카더라식의 정보나 공인중개사의 말을 일방적으로 믿기보다는 스스로 관련 조항에 대해 공부하고 대비책을 마련하여 하자 발생 시 리스크를 헷징하는 것이 가장 최선의 길이라고 생각한다.

“세상에 내 편은 아무도 없고, 결국 모든 계약을 진행 할 때는 스스로를 지킬 방법을 항상 연구하자” 오늘의 교훈.

(저는 법률 전문가가 아니며, 위 내용은 법률 전문가의 검토를 받은 사항도 아닙니다. 부동산과관련된 모든 결정과 판단은 본인의 책임하에 신중하게 진행 하시길 바랍니다.)