나는 꽤 나쁜 상황에 처해 있으며 그것을 실패라고 부르기 전에 약간의 통찰력을 찾고 있습니다.
상황을 이해하기 위해 먼저 파티셔닝 체계를 설명하겠습니다.
4개의 디스크로 구성된 btrfs 파일 시스템(btrfs raid0 모드를 통해 데이터가 배포됨)이 있는 서버가 있습니다. 각 디스크에는 btrfs 데이터가 포함된 LUKS 암호화 파티션이 있으며, 각 LUKS 파티션은 initramfs 내의 암호화된 파일에 있는 단일 키 슬롯으로 보호됩니다. LUKS 키 스크립트는 스마트 카드를 사용하여 이러한 시작 키를 자동으로 해독합니다.
이제 문제가 발생합니다.
몇 달 전에 저는 btrfs 파일 시스템을 확장하고 새 디스크를 추가하고 암호화하고 부팅 키를 저장하는 등의 작업을 수행해야 했습니다. 그러나 프로세스의 중요한 부분을 간과하고 update-initramfs를 실행하는 것을 잊어버렸습니다. 그러면 새로운 암호화된 부팅 키가 initramfs에 전파됩니다. 오늘 정전으로 인해 서버가 재부팅되었으며, 확인해보니 /var/lib/bootkeys에 새로 추가된 디스크의 키가 포함되어 있지 않았습니다!
이것은 나에게 실질적인 질문을 제기합니다.
내 btrfs 파일 시스템(현재 25% 손실)에 포함된 부팅 키 파일이 내가 아직 액세스할 수 있는 세 개의 디스크 중 하나에 있을 가능성이 있습니까? 그렇다면 해당 시작 키를 복구하고 파일 시스템에 대한 전체 액세스 권한을 다시 얻을 수 있습니까?
우선 다음 명령을 실행해 보았으나 의미 있는 출력이 생성되지 않거나 파일을 복구하는 것 같습니다(/dev/mapper/c{0,2}는 해독된 디스크에서 읽을 수 있음).
btrfs restore --path-regex '^/(|var(|/lib(|/bootkeys(|/.*))))$' /dev/mapper/c0 /mnt/recovery0
btrfs restore --path-regex '^/(|var(|/lib(|/bootkeys(|/.*))))$' /dev/mapper/c1 /mnt/recovery1
btrfs restore --path-regex '^/(|var(|/lib(|/bootkeys(|/.*))))$' /dev/mapper/c2 /mnt/recovery2