지난 편에서 나스 하드를 윈도우에 연결했더니 RAW로만 잡히더라는 이야기를 적었습니다. 윈도우로는 안 된다는 걸 알았으니 다음 수순은 리눅스였습니다.
노트북에 우분투를 띄우고 하드를 연결했습니다. 우분투 설치 USB를 만들고 설정하는데 까지 며칠이 갔습니다. 그리고 치열하게 사투를 벌였지만 결국 데이터는 꺼내지 못했습니다.
이 글은 성공기가 아닙니다. 어디서 어떻게 막혔는지, 지금 돌아보면 무엇이 잘못이었는지에 대한 기록입니다. 같은 상황에 놓인 분이 저와 같은 길로 가지 않으셨으면 해서 남깁니다.
리눅스라면 열릴 줄 알았습니다
시놀로지는 리눅스 기반이니 리눅스에서는 당연히 읽힐 거라고 생각했습니다. 쉽게 생각했지만 결코 쉽지 않았습니다.
리눅스가 그 형식들을 다룰 수 있는 건 사실입니다. 다만 자동으로 열어주지는 않습니다. 지난 편에서 말한 층들을 하나씩 손으로 조립해 올려야 합니다. RAID를 깨우고, 그 위에 LVM을 올리고, 그 위에서 파일 시스템을 마운트하는 순서입니다. 특히 저같이 문과생들에게는 이 하나하나의 과정이 결코 쉬운 것이 아니었습니다.
그래도 요새는 AI가 많은 도움을 줄 수 있는 시대이니만큼 일말의 기대를 가지고 작업을 시작했습니다.
첫 시도부터 막혔고, 진단은 계속 바뀌었습니다
우선 RAID를 조립하는 명령부터 넣었습니다. 돌아온 건 이런 메시지였습니다.
mdadm: no recognisable superblock on /dev/sda1
수퍼블록은 이 디스크가 어떤 RAID의 몇 번째 조각인지 적어둔 표식입니다. 그게 없다는 건 “여기가 RAID 조각으로 안 보인다”는 뜻입니다.
그다음엔 파일 시스템을 직접 마운트해 봤습니다. 이번엔 이렇게 나왔습니다.
mount: /mnt/syno_final: 잘못된 파일 시스템 형식, 불량 옵션,
/dev/sda1에 불량 수퍼블록...
층을 건너뛰어도, 순서대로 올라가도 같은 자리에서 막혔습니다.
이 과정을 AI에게 물어가며 진행했습니다. 그때 오간 대화를 지금 다시 읽어보면 진단이 계속 뒤집혔습니다. 처음에는 RAID 구조라서 그렇다고 했습니다. 그래서 시작 지점을 강제로 지정하는 방법으로 갔습니다. 그래도 안 되니 이번엔 “애초에 RAID를 안 거친 구조인 것 같다”며 파일 시스템 직접 마운트로 방향을 틀었습니다. 그것도 실패하자 다시 시작 지점 이야기로 돌아왔습니다.
AI를 탓하려는 게 아닙니다. 저도 확신이 없었고, 확신이 없는 채로 명령어만 계속 바꿔 넣고 있었습니다. 둘 다 같은 실수를 하고 있었습니다.
증상을 보고 원인을 좁힌 게 아니라, 떠오르는 방법을 순서대로 시도하고 있었습니다. 이게 이 실패의 진짜 원인이라고 생각합니다.
진짜 단서는 처음부터 화면에 있었습니다
지금 돌아보면 놓친 게 있습니다. 디스크를 확인했을 때 파티션이 하나만 잡혀 있었습니다. sda1 하나가 3.6TB 통째로요.
이게 이상한 겁니다. 시놀로지는 보통 디스크 하나를 세 조각으로 나눠 씁니다.
| 파티션 | 크기 | 용도 |
|---|---|---|
| sda1 | 약 2.4GB | DSM 시스템 |
| sda2 | 약 2GB | 스왑 |
| sda3 | 나머지 전부 | 실제 데이터 |
데이터는 sda3에 있어야 정상입니다. 그런데 제 화면에는 sda3가 없었고, sda1이 디스크 전체 크기로 잡혀 있었습니다. 이건 “이 디스크의 파티션 구조가 제대로 안 읽히고 있다”는 신호였습니다. 그 상태에서 아무리 정교한 명령을 넣어도 애초에 엉뚱한 곳을 가리키고 있었던 셈입니다.
저는 이 신호를 보고도 그냥 지나갔습니다. 화면에 답이 있었는데 명령어를 바꾸는 데만 집중하고 있었습니다.
왜 파티션이 안 보였는지는 이제 확인할 방법이 없어 단정하지 못합니다. 다만 연결 방식이 원인일 가능성이 있습니다. USB 외장 케이스나 도킹스테이션을 거치면 중간의 변환 칩이 디스크의 섹터 크기를 원래와 다르게 보고하는 경우가 있습니다. 그러면 파티션 표를 읽는 위치가 어긋나서 구조가 통째로 안 보일 수 있습니다. 이 경우 해결은 의외로 단순합니다. 데스크톱에 SATA로 직접 연결하는 것입니다.
다른 이유였을 수도 있습니다. 어느 쪽이든 순서는 같습니다. 파티션이 정상적으로 보이는 상태를 먼저 만들고, 그다음에 조립을 시작해야 합니다.
같은 상황이라면 이 순서로 하시기 바랍니다
제가 했어야 할 순서를 정리해 둡니다. 전부 읽기 전용이라 디스크에 쓰지 않습니다. 다만 이건 표준 절차이지 제가 성공을 확인한 절차는 아니라는 점을 밝혀둡니다.
먼저 필요한 도구를 설치합니다.
sudo apt install mdadm lvm2 btrfs-progs
그리고 디스크가 어떻게 보이는지부터 확인합니다.
lsblk
sudo fdisk -l /dev/sda
여기서 sda1, sda2, sda3 세 개가 보이는지 확인합니다. 안 보이면 그 문제부터 해결해야 합니다. 연결 방식을 바꿔보는 게 먼저입니다. 파티션이 안 보이는 상태에서 다음 단계로 넘어가면 안 됩니다.
정상적으로 보인다면 그다음은 이렇게 이어집니다.
sudo mdadm --assemble --scan
sudo pvscan && sudo vgscan && sudo vgchange -ay
sudo mount -o ro /dev/vg1000/lv /mnt/복구폴더
볼륨 그룹 이름은 DSM 버전에 따라 다를 수 있으니 vgscan 결과에 나온 이름을 그대로 쓰시면 됩니다. 마운트가 안 되면 -o ro,usebackuproot 같은 복구 옵션을 붙여볼 수 있습니다.
ro는 빼지 마세요. 읽기 전용이라는 뜻이고, 이게 있어야 실수로 디스크에 쓰는 일이 없습니다.
어디서 멈춰야 했나
며칠을 매달렸지만 결국 실패했습니다. 그리고 저는 새 NAS를 샀습니다.
새 NAS를 켜면서 그 하드를 그대로 넣었습니다. 초기화 과정에서 디스크는 새로 구성됐고, 그 순간 안에 있던 데이터는 완전히 사라졌습니다.
아이의 4살까지의 그 많은 사진, 동영상이 날아갔습니다. NAS의 백업을 믿고 핸드폰의 사진을 지웠었는데, 하필이면 구글포토 백업이 되어있지 않은 시기의 사진, 동영상들을 모두 날렸습니다.
이제 와서 가장 후회되는 건 그겁니다. 복구에 실패한 것보다, 가능성이 남아 있는 상태에서 덮어써 버린 것이요.
전문 복구 업체에 맡기는 선택지가 있었습니다. 비용이 부담되면 견적만이라도 받아볼 수 있었습니다. 아니면 그 하드를 그냥 보관해 두고 새 디스크를 사는 방법도 있었습니다. 4TB 하드 한 개 값과, 그 안에 있던 몇 년치 사진을 비교하면 답은 분명했습니다.
살릴 수 있을지 확신이 없을 때는, 일단 손대지 않는 게 답입니다.
정리
- 리눅스에서도 나스 하드는 자동으로 안 열립니다. 층을 순서대로 조립해야 합니다.
- 조립 전에 파티션이 정상적으로 보이는지부터 확인하시기 바랍니다.
sda1만 통째로 잡힌다면 그 문제부터 해결해야 합니다. - USB 도킹보다 SATA 직결이 안전합니다. 중간 변환 단계가 구조를 흐트러뜨릴 수 있습니다.
- 명령어를 바꿔가며 시도하기 전에, 화면에 이미 나와 있는 정보를 다시 보시기 바랍니다.
- 마운트는 항상
ro(읽기 전용)로 합니다. - 확신이 없으면 그 디스크는 그대로 두시기 바랍니다. 새 디스크를 사는 비용이 데이터보다 쌉니다.
다음 편부터는 새로 산 NAS를 어떻게 구성했는지 적겠습니다. 같은 일을 두 번 겪지 않으려고 무엇을 바꿨는지도요.