.png)
머리말:
데이터 복구에 관한 질문이기 때문에 "백업은 어디에 있습니까?"라는 질문에 "답변이 없는 경우"가 많을 것으로 예상됩니다. 또는 "이미지의 블록 수준 복사본에서 이 작업을 수행합니다." 고마워요, 이해합니다. 더 이상 가르쳐 줄 필요가 없습니다. 내용과 이유는 마지막에 있는 참고 사항을 참조하세요. 감사해요.
내 JFS 파일 시스템 이미지가 손상되었습니다.jfs_fsck다음 오류 메시지와 함께 처리가 거부되었습니다.
~ % sudo jfs_fsck /dev/loop0
jfs_fsck version 1.1.15, 04-Mar-2011
processing started: 3/1/2017 13:08:53
Using default parameter: -p
The current device is: /dev/loop0
Superblock is corrupt and cannot be repaired
since both primary and secondary copies are corrupt.
CANNOT CONTINUE.
사용jfs_debugfs명령을 실행 su하고 s2p다음 정보를 얻습니다.
~ % sudo jfs_debug /dev/loop0
jfs_debugfs version 1.1.15, 04-Mar-2011
Aggregate Block Size: 4096
출력 su p:
[1] s_magic: 'JFS1' [15] s_ait2.addr1: 0x00
[2] s_version: 1 [16] s_ait2.addr2: 0x0000e92f
[3] s_size: 0x000000015d4d4ec0 s_ait2.address: 59695
[4] s_bsize: 4096 [17] s_logdev: 0x00000900
[5] s_l2bsize: 12 [18] s_logserial: 0x0009afb1
[6] s_l2bfactor: 3 [19] s_logpxd.len: 8192
[7] s_pbsize: 512 [20] s_logpxd.addr1: 0x00
[8] s_l2pbsize: 9 [21] s_logpxd.addr2: 0x2baa0160
[9] pad: Not Displayed s_logpxd.address: 732561760
[10] s_agsize: 0x00800000 [22] s_fsckpxd.len: 22408
[11] s_flag: 0x10200900 [23] s_fsckpxd.addr1: 0x00
JFS_LINUX [24] s_fsckpxd.addr2: 0x2ba9a9d8
JFS_COMMIT JFS_GROUPCOMMIT s_fsckpxd.address: 732539352
JFS_INLINELOG [25] s_time.tv_sec: 0x4902c28b
[26] s_time.tv_nsec: 0x00000000
[27] s_fpack: 'thor_storag'
[12] s_state: 0x00000001
FM_MOUNT
[13] s_compress: 0
[14] s_ait2.len: 4
출력 su s:
[1] s_magic: ' ' [15] s_ait2.addr1: 0x00
[2] s_version: 0 [16] s_ait2.addr2: 0x00000000
[3] s_size: 0x0000000000000000 s_ait2.address: 0
[4] s_bsize: 0 [17] s_logdev: 0x00000000
[5] s_l2bsize: 0 [18] s_logserial: 0x00000000
[6] s_l2bfactor: 0 [19] s_logpxd.len: 0
[7] s_pbsize: 0 [20] s_logpxd.addr1: 0x00
[8] s_l2pbsize: 0 [21] s_logpxd.addr2: 0x00000000
[9] pad: Not Displayed s_logpxd.address: 0
[10] s_agsize: 0x00000000 [22] s_fsckpxd.len: 0
[11] s_flag: 0x00000000 [23] s_fsckpxd.addr1: 0x00
[24] s_fsckpxd.addr2: 0x00000000
s_fsckpxd.address: 0
[25] s_time.tv_sec: 0x00000000
[26] s_time.tv_nsec: 0x00000000
[27] s_fpack: ''
[12] s_state: 0x00000000
FM_CLEAN
[13] s_compress: 0
[14] s_ait2.len: 0
출력 s2p p:
[1] s_magic: 'JFS1' [16] s_aim2.len: 2
[2] s_version: 1 [17] s_aim2.addr1: 0x00
[3] s_size: 0x000000015d4d4ec0 [18] s_aim2.addr2: 0x0000e92d
[4] s_bsize: 4096 s_aim2.address: 59693
[5] s_l2bsize: 12 [19] s_logdev: 0x00000900
[6] s_l2bfactor: 3 [20] s_logserial: 0x0009afb1
[7] s_pbsize: 512 [21] s_logpxd.len: 8192
[8] s_l2pbsize: 9 [22] s_logpxd.addr1: 0x00
[9] s_agsize: 0x00800000 [23] s_logpxd.addr2: 0x2baa0160
[10] s_flag: 0x10200900 s_logpxd.address: 732561760
LINUX [24] s_fsckpxd.len: 22408
GROUPCOMMIT [25] s_fsckpxd.addr1: 0x00
INLINELOG [26] s_fsckpxd.addr2: 0x2ba9a9d8
s_fsckpxd.address: 732539352
[11] s_state: 0x00000001 [27] s_fsckloglen: 50
MOUNT [28] s_fscklog: 2
[12] s_compress: 0 [29] s_fpack: 'thor_storagة�+'
[13] s_ait2.len: 4
[14] s_ait2.addr1: 0x00
[15] s_ait2.addr2: 0x0000e92f
s_ait2.address: 59695
출력 s2p s:
[1] s_magic: ' ' [16] s_aim2.len: 0
[2] s_version: 0 [17] s_aim2.addr1: 0x00
[3] s_size: 0x0000000000000000 [18] s_aim2.addr2: 0x00000000
[4] s_bsize: 0 s_aim2.address: 0
[5] s_l2bsize: 0 [19] s_logdev: 0x00000000
[6] s_l2bfactor: 0 [20] s_logserial: 0x00000000
[7] s_pbsize: 0 [21] s_logpxd.len: 0
[8] s_l2pbsize: 0 [22] s_logpxd.addr1: 0x00
[9] s_agsize: 0x00000000 [23] s_logpxd.addr2: 0x00000000
[10] s_flag: 0x00000000 s_logpxd.address: 0
[24] s_fsckpxd.len: 0
[25] s_fsckpxd.addr1: 0x00
[26] s_fsckpxd.addr2: 0x00000000
s_fsckpxd.address: 0
[11] s_state: 0x00000000 [27] s_fsckloglen: 0
CLEAN [28] s_fscklog: 0
[12] s_compress: 0 [29] s_fpack: ' '
[13] s_ait2.len: 0
[14] s_ait2.addr1: 0x00
[15] s_ait2.addr2: 0x00000000
s_ait2.address: 0
이제 문제는 슈퍼블록에서 어떤 값을 조작해야 하느냐는 것입니다.jfs_fsck누구든지 내가 작동하도록 설득할 수 있나요? 아니면 마운트할 수 있나요(Linux jfs 커널 파일 시스템을 사용하여 구현됨)?
파일 시스템 이미지를 살펴보고 그 안에 파일이라고 생각되는 모든 것을 뱉어낼 수 있는 도구가 있다면 완벽하게 수용 가능합니다.
미주
내가 통제하는 일부 이벤트로 인해 JFS 파일 시스템이 포함된 Linux mdadm RAID-5가 어떤 방식으로든 손상되었으며 오늘날까지도 어떤 오류 모드를 이해하지 못합니다. 이 FS는 제가 다른 사람과 공유하는 NAS의 일부입니다. 저는 그에게 RAID가 백업을 대체하지 않는다는 점을 반복해서 상기시켰습니다. 그러나 이러한 경고에도 불구하고 다른 사람은 여전히 해당 RAID에 백업되지 않은 일부 데이터를 가지고 있습니다(이제 반분노단계... 이런 느낌이 드네요). 우리의 즉각적인 조치는 시스템에서 디스크를 제거하고 해당 디스크의 블록 수준 복사본을 만드는 것이었습니다. 내가 하려는 모든 조작은 다음에서 발생합니다.스냅 사진이러한 복사본을 사용하면 복구 중에 어떤 일이 발생하더라도 언제든지 롤백할 수 있습니다.
어제 마침내 mdadm RAID를 (일관되길 바라는) 상태로 복원할 수 있었습니다.
기본적으로 나는 거기에 있는 것을 복원하고 그것을 하루라고 부르고 싶습니다.