죠슈아 2020-07

레이드 구성 이거나 SHR  볼륨 이므로 복구 하는데 시간이 몇일  또는 일주일 이상 소요 됩니다.
그리고 디스크를 리눅스 머신에 연결하거나 하는 방법으로 데이터 복구 하는 것도 간단 하지 않습니다.

시간이 오래 걸려도 ...  데이터 복구가 중요 하면 .. 복구될때까지 기다리는 것이 최선 입니다.
복구중 전원을 끄거나하며 .. 하면 복구 불가도 될 수 있습니다.
메시지가 recoverable 상태로 나오고 있으므로 .. 불가 라는 메시지가 아니니 ... 계속 진행 하는 것이 최선 입니다.
 drive를 3개 ?  볼륨 크기가 얼마인지 설명이 없어서 ..
볼륨 크기가 수 테라 이면 일주일은 족히 기다려야만 합니다.

만무라비 2020-07

답변 감사합니다.

실제로 확인해보니 복구 작업이 진행되고 있는게 아닌 것으로 보입니다. 그렇게 판단한 계기는 HDD가 돌지 않고, 지속적으로 recoverable 를 수행하면 계속 지속적인 재부팅이 일어났기 때문입니다...
그리고 loader / boot mode / controller 구성 / guestOS 구성에 따라 정상적으로 구동이 안되는 것으로 확인했습니다.
현재는 ESXi 6.7 / Other 3.x linux / 1.03b loader(DS3615xs) / legacy(BIOS) / sata or SCSI / DSM 6.2.3 조합으로 부팅은 되었지만, migration 항목을 수행하면, "Failed to install the file. The file is probably corrupted (13)." 에러 메시지에서 지속적으로 진행이 안되고 있는 상황입니다.
제 H/W spec이 i7-2670 / 8GB / Intel DH67BL 사양이라, DS918+에 대한 조합은 안되는 것으로 보이며, 결국 DS3615 또는 DS3617 만 가능한 것으로 보입니다.
reference : https://xpenology.com/forum/topic/13333-tutorialreference-6x-loaders-and-platforms/

혹시, 위 에러에 대한 특별한 조건이나 다른 회피 방안이 있다면 조언을 부탁드리겠습니다.

감사합니다.

죠슈아 2020-07

최종적으로 DSM 6.2.3 이 로드되어서 Xpenology 가동작 되는 상태 이지만 볼륨을 인식 하지 못하는 상태 인가요?
가상 머신으로 Xpenology 를 설치했다면 디스크 구성은 Xpenology 만을 위해 따로 네이티브로 디스크를 add 한 상태 인가요?
가상 머신의 디스크 볼륨을 생성 하고 거기에 일부 파티션을 Xpenology 볼륨으로 할당 하신 것인가요?

1. 네이티브로 디스크를 할당 했다면 해당 디스크를 다른 머신에 (리눅스 부팅되는 기기) 디스크를 마운트 해서 파일을 복구 하는방법
2. 가상 머신의 디스크 볼륨을 생성해서 Xpenology 볼륨으로 할당 했다면  Xpenology 동작 상태에서 linux 용 파일 복구 S/W 사용하는 방법

각각의 방법을 실행 하기전에 디스크의 내용 변경이 발생하지 않는 것을 전제로 시도를 하셔야만
이런 저런 시도를 할 수 있습니다.
1번 방법을 위해서 Xpenology 볼륨만 마운트를 시도해 보시죠.
디스크 파티션 정보를 리스트하면 가장큰 파티션이 이에 해당 합니다.
파일 시스템을 SHR 로 했나요? EXT4 로 하셨나요?  아니면 BTRFS 으로 하셨나요...
아래 링크를 검토해보세요.
https://m.blog.naver.com/PostView.nhn?blogId=star-com&logNo=221456680518&proxyReferer=https:%2F%2Fwww.google.com%2F

3개 디스크로 구성했다고 했으니 2번에 해당하는 방법으로 하시지 않았겠지만
레이드 구성을 하셨다면 위 링크느 도움이 되지 않을 수도 있습니다. 단일 디스크에 해당 하니까요.

아래 링크는
https://hogoo.tistory.com/2303
여러개의 btrfs 볼륨으로 각각 윈도우에서 인식 되는 방법을 설명 합니다만 ..
님의 상황과 맞지 않을 수도 있습니다.

우분투에서 BTRFS 볼륨 마운트를 설명 하는 링크 입니다.
https://jkpark.github.io/ubuntu1804/05-btrfs
마운트만 시도해서 확인 해야만 합니다.
파티션을 생성 하거나 하시면 데이터를 영영 잃어버리게 됩니다.


아래 링크도 검토하시기 바랍니다.
https://www.it-swarm-ko.tech/ko/mount/nas-os-%ec%b6%a9%eb%8f%8c-shrology%ec%9d%b4%ec%9e%88%eb%8a%94-shr-raid-%eb%93%9c%eb%9d%bc%ec%9d%b4%eb%b8%8c/961105125/
https://askubuntu.com/questions/882121/shr-raid-drives-with-crashed-nas-os-synology
위링크는 아래 영문 내용을 단순 번역 해서 올린 것이군요.

만무라비 2020-07

답변 감사드립니다.

제가 확인이 늦었네요... RDM 으로 구성하고 향후 복원을 위해 RAID 구성은 하지 않았습니다. 모두 단일 disk 구성으로 해놓았었습니다. 그 편이 나중에 관리하기 편해서요.
결과론적으로 DSM 버전 마다 인식하는 system partition에 대한 mismatch가 있었던 것이나, 아니라면 뭔가 부트로더 특성에 따라서 호환이 잘 안되는 상황일거라 추정합니다.
1.02b (DS3615xs) + DSM 6.1.7 로 정상적으로 migration이 완료되었습니다.
도움 감사드립니다.