시놀로지 볼륨 복구 - sinolloji bollyum boggu

rsync 명령어를 직접 입력해서 공유 폴더의 파일을 백업합니다.

공유폴더의 파일과 나스 설정을 모두 백업합니다. 디스크는 4개 모두 교체합니다. 3TB 디스크 1개는 정상이지만 4년 정도 사용했으므로 모두 교체하기로 했습니다. DSM을 새로 설치한 다음, 백업받은 설정으로 복원합니다. 백업받은 공유폴더의 파일을 다시 원래의 공유폴더에 복사합니다. 

1. 임시로 사용할 시놀로지 나스를 준비합니다.
2. DS918+의 공유 폴더에 들어있는 파일을 임시로 사용할 나스에 복사합니다.
3. DS918+의 디스크를 교체하고 DSM을 새로 설치합니다. 나스의 설정을 기존과 똑같이 설정합니다.
4. 임시로 사용하는 나스에 들어있는 파일을 다시 DS918+에 복사합니다.

DS918+의 공유 폴더를 임시로 사용하는 나스에 복사합니다.

파일을 복사하는 도중에 디스크의 오류가 계속 감지됩니다. 만약 복사가 진행되지 않고 오류만 계속 감지된다면 복사를 중단해야합니다. 파일을 읽지 못하는 디스크를 계속해서 사용하면 디스크가 점점 더 손상될 수 있기 때문입니다.

파일이 복사되지 않는 경우에는 데이터 복구업체에 의뢰해서 파일을 복구해야 합니다. 데이터 복구업체에서도 손상이 많은 디스크일수록 파일을 복구하기가 어렵습니다. 파일을 하나라도 더 살리려면 디스크가 조금이라도 덜 고장난 상태에서 맡겨야합니다.

공유 폴더 한 개를 rsync 명령어로 복사한 결과입니다. 나머지 공유폴더도 차근차근 복사합니다.

2021/10/19 20:27:22 [28585] Number of files: 151285
2021/10/19 20:27:22 [28585] Number of files transferred: 127860
2021/10/19 20:27:22 [28585] Total file size: 1082472299062 bytes
2021/10/19 20:27:22 [28585] Total transferred file size: 1082472299062 bytes
2021/10/19 20:27:22 [28585] Literal data: 1082472299062 bytes
2021/10/19 20:27:22 [28585] Matched data: 0 bytes
2021/10/19 20:27:22 [28585] File list size: 6523298
2021/10/19 20:27:22 [28585] File list generation time: 0.001 seconds
2021/10/19 20:27:22 [28585] File list transfer time: 0.000 seconds
2021/10/19 20:27:22 [28585] Total bytes sent: 1082616316230
2021/10/19 20:27:22 [28585] Total bytes received: 2523051
2021/10/19 20:27:22 [28585] sent 1082616316230 bytes received 2523051 bytes 50002024.77 bytes/sec
2021/10/19 20:27:22 [28585] total size is 1082472299062 speedup is 1.00

공유폴더의 파일을 임시로 사용하는 나스에 모두 복사했으면 작업의 90%를 완료한 것과 다름없습니다. 하드디스크를 교체하고, DSM을 설치하고, 임시로 사용하는 나스에 들어있는 파일을 다시 DS918+로 복사하는 작업이 남았는데요. 이런 작업은 충돌한 볼륨에 들어있는 파일을 빼는 작업에 비하면 아주 손쉬운 작업에 속하기 때문입니다.

지난 금요일 저녁, 부부의 세계가 끝나고 정전이 발생하면서 우리 지역구내 동전체가 정전이 되는 사태가 발생한적이 있다.

당연히 집에서 운영중이던 microserver가 죽어버렸고, 내부에 가상으로 돌던 xpenology가 떨어져버렸다.

재 접속한 DSM은 이전처럼 볼륨 충돌이 표시되고 있었고 별로 대수롭지 않게 생각하고 있었다.

그도 그럴것이 늘상 있었던 일이고 대부분의 경우 DSM의 특정 DISK가 충돌이 된 경우고 이경우 해당 디스크 복구를 통해 복구가 가능했었다. 

이때까지는 그랬다.

그런데 이번에 충돌은 Volume 자체가 충돌이 되어 복구기능도 모두 비활성화 되어 있어 어떤 액션도 할 수 없었다.

일단 이글을 검색해 들어오는 분들을 위해 증상을 나열 해 놓을테니 자신의 증상과 동일하다면 한번 시도 해보자.

볼륨을 깨고 새로 시작하는것보다 빠르고 간단하다.

한번도 보지 못한 오류케이스로 정신없이 복구하다보니 캡쳐따윈 없다.

지금 캡쳐는 정상적인 모습이지만 우측의 시스템상태에 볼륨 충돌이 표시되고 있었다.

자세한 정보는 저장소 관리자를 참조하란 메시지가 떠있는데 들어가보자.

상기 이미지처럼 특별한 문제가 없는 상태였다. 단순 볼륨만 충돌된 상태였다.

정말로 아무런 문제 없이 정상으로 표기되고 있었는데 볼륨만 충돌되어 있었다.

그리고 SSH로 nas에 접속해 보면 예상대로 이상한점을 볼 수 있다.

본인은 nas에 6TB를 묶어 두었는데 SSH로 접속한 NAS에서는 찾아볼 수 없었다.

아마 이글을 검색해 들어온 분들은 이미 스스로 체크할 수있는 문제점은 모두 체크했고, 

시도할 수 있는 대부분의 것들은 시도 했으리라 생각된다.

이번 볼륨 충돌로 시도해본것들을 나열해 본다.

가장먼저 간단한 조치부터 진행했다. 

1. 재부팅

재부팅은 전혀 도움이 되지 않았다.

2. 가상 디스크를 모두 제거하고 부팅한뒤, 다시 가상 디스크를 붙여 재부팅

역시 효과 없었다.

3. SYNOBOOT 이미지 재작성.

이미지를 재작성하여 migration을 진행했다.

역시 아무런 도움이 되지 않았다. 덕분에 버전만 업했다.

4. 새로 xpenology를 생성하고 새 가상disk를 추가한다음 최초 설정까지 마치고 백업을 위한 disk를 모두 다시 연결하여 부팅한다.

이것은 해외에 많이들 추천되고 시도되는 작업인데 일부는 성공하고 일부는 실패하는듯 했다.

나또한 시도해 봤지만 바로 실패했다.

5. SATA 포트를 변경한다.

이또한 변화가 없었다.

ssh에 접속해서 본 시스템엔 내 파일 시스템이 정상이 아니란 생각에 일단은 마운트를 시켜야 한다는 생각에 마운트 방법만 찾게 되었고 그중에 찾은 방법이 복구가 가능했던 방법이다.

본인은 file system이 btrfs라 아래와 같은 명령어를 사용하지만 ext4를 사용하는 사용자는 다른 명령어를 사용해야 한다. 이부분은 햇갈리면 fstab에서 마운트 타입을 확인하자.

btrfs check --repair /dev/md2

btrfs rescue chunk-recover /dev/md2

btrfs check --init-extent-tree /dev/md2

btrfs check --init-csum-tree /dev/md2

입력하고 기다리자

sudo mount -o recovery,ro /dev/md2 /volume1

으로 md2를 /volume1에 마운트하자.

조금 기다리면 마운트가 되고 디렉토리내 file들을 확인할 수 있다.

확인된 file을 그대로 백업할 사람들은 백업을 하던 하면 되고, 그대로 시스템을 살릴 목적이라면 아래의 명령어를 더 입력하자.

sudo btrfs rescue super /dev/md2

busy로 나온다면 일단은 다음으로 넘어가고 진행이 되면 기다리자. 대부분은 busy로 표시된다.

sudo btrfs-find-root /dev/md2

명령어로 복구를 진행하자. 정상인경우 0이 return되고 비정상인경우 1이 return된다. 

나의 경우 1이 return되고 대략 40분정도 소요가 되었다.

그리고 재부팅한다. 

평소보다 화면이 올라오는데 시간이 많이 소요된다면 성공이다.

기다렸다 접속하면 모든 시스템은 정상으로 돌아와 있다.

이 경우는 본인에 해당하는 경우이겠지만 다른 사람의 경우도 해당하리라 생각하여 공유한다.

반대로 본인이 또 같은 상황을 겪을때 참고를 위한 자료이기도 하다.