컨테이너를 백업할까, 그 안의 파일을 백업할까? 복원 형태로 정한다
이미지 단위와 파일 단위 백업은 복원하는 대상이 다르고 필요한 키도 다릅니다. 보관할 대상을 실제로 필요한 복원에 맞추십시오.
암호화된 컨테이너는 하나의 객체로 통째로 백업할 수도 있고, 마운트해서 안의 파일을 백업할 수도 있습니다. 둘 다 VPN을 문제없이 통과하지만, 비슷한 것은 거기까지입니다. 복원되는 대상이 다르고, 의존하는 키가 다르고, 필요한 용량이 다르고, 누군가 데이터를 되찾아야 할 때 실패하는 방식도 다릅니다. 먼저 복원 대상을 정하고, 다음에 전송 수단을, 마지막으로 보관 사본의 암호화를 정합니다. 아래 점검 목록도 그 순서를 따릅니다. 백업을 둘러싼 거의 모든 논쟁은 사실 이 세 가지 중 무엇을 먼저 정했는지에 대한 이견이기 때문입니다.
두 대상, 두 가지 복원 형태
이미지 단위 백업이 복원하는 것은 컨테이너입니다. 암호화된 볼륨은 돌아오지만, 그것을 열려면 복원용 재료가 따로 필요합니다. 파일 단위 백업이 복원하는 것은 파일과 디렉터리 트리이며, 이를 보호하는 암호화는 원래 컨테이너가 아니라 백업 저장소의 성질입니다. 원격 폴더로의 단순 복사는 세 번째 경우이고, 그 폴더가 우연히 갖고 있는 보호를 그대로 물려받습니다.
| Object | What a restore gives you | Where the encryption question lands |
|---|---|---|
| Encrypted container image | The volume, still locked | The container format and its recovery key material |
| Mounted files into a backup tool | Selected files and metadata | The backup repositorys own keys and design |
| Plain copy to a remote folder | Whatever the copy process kept | Whatever protects that storage afterwards |
가운데 행이 사람들이 잘못 읽는 부분입니다. 이것은 충분히 좋은 설계일 수 있습니다. 백업 프로그램이 로컬에서 평문을 읽고 암호화·인증된 저장소를 씁니다. 그러면 보안은 그 프로그램과 그 자격 증명에 기대며, 원래 컨테이너의 암호에 기대지 않습니다. 둘을 같은 통제로 설명해서는 안 됩니다.
점검 1: 복원은 무엇을 재구성해야 하는가
질문은 백업이 아니라 복원의 형태로 던집니다. 요구가 “이 서비스를 다른 호스트에서 되살린다”라면 이미지와 복원용 재료가 일관된 답입니다. 요구가 “삼월 재무 스프레드시트를 되찾는다”라면 파일 하나를 꺼내기 위해 몇 기가바이트짜리 이미지를 복원하는 것은 비싼 답입니다. 둘 다 정당한 복원이고, 서로 대체할 수 있는 예산이 아닙니다. 한쪽만 언급한 계획은 결국 다른 쪽으로 시험받습니다.
복원 목표를 계획에 적습니다. 볼륨 전체, 디렉터리 트리, 개별 파일 중 하나입니다. 이어서 어떤 메타데이터가 함께 이동해야 하는지 적습니다. 소유권, 권한, 확장 속성, 타임스탬프는 파일 단위 복원의 일부이며, 시험할 때 충분해 보였던 복사 중심 절차에서 자주 빠지기 때문입니다.
복원을 누가 수행하는지도 정합니다. 어떤 운영자든 마운트할 수 있는 파일 단위 저장소는 키 보유자의 입회를 요구하는 이미지와는 다른 접근 모델이며, 어느 쪽이 자동으로 더 낫지도 않습니다. 중요한 것은 선택이 의도적이고 문서화되어 있다는 점입니다.
점검 2: 보관 사본을 보호하는 것은 무엇인가
VPN이 보호하는 것은 전송 구간입니다. 전송이 끝난 뒤의 보관 사본에 대해서는 아무 말도 하지 않으며, “터널을 지났다”는 백업 운영자가 당신의 데이터를 읽을 수 있는지에 대한 진술이 아닙니다. 원격 쪽을 다른 누군가가 운영한다면 물어야 할 것은 상대가 무엇을 읽을 수 있는지이지, 회선이 암호화되었는지가 아닙니다.
이미지라면 컨테이너의 키 재료를 이미지 자체와 분리해 보호한다는 뜻입니다. 헤더를 잃으면 볼륨을 잃으므로, 이미지가 없는 곳에 헤더를 백업합니다.
cryptsetup luksHeaderBackup /dev/vg0/data --header-backup-file data-header.img
cryptsetup luksDump /dev/vg0/data | head -20파일 단위 저장소라면 호스트를 떠나기 전에 내용과 메타데이터를 암호화하고 인증하는지 확인하고, 키를 누가 보관하는지 파악합니다. Restic의 설계 문서 는 신뢰할 수 있는 원본 호스트를 전제하며 암호화가 저장소 접근 권한을 가진 사람의 백업 삭제를 막지 않는다고 분명히 밝힙니다. 두 단서 모두 중요합니다. 저장소는 기밀일 수 있으면서도 파괴될 수 있습니다.
점검 3: 사본은 일관적인가
변화하는 파일 시스템을 담은 백업은 복원 지점이 아니라 사본입니다. 이미지라면 볼륨 도구가 지원하는 방법으로 안정적인 스냅샷을 만듭니다. 큰 파일이 바뀌는 동안 읽는 대신 스냅샷 작업이나 마운트 해제를 쓰는 것이 보통입니다.
lvcreate -L 5G -s -n data-snap /dev/vg0/data
cryptsetup open /dev/vg0/data-snap data-snap --readonly마운트된 파일이라면 가동 중인 데이터베이스와 그 밖의 조정된 데이터에 대해 애플리케이션이 지원하는 일관성 절차를 씁니다. 파일 시스템 단위 사본과 애플리케이션 일관성 복원 지점은 다른 설명이며, 그 차이는 복원한 사본에서 애플리케이션을 시작하려 할 때에야 드러납니다.
복원용 재료는 독립된 보호 경로에 둡니다. 원래 기계를 잃는 것이 그 백업을 여는 유일한 자격 증명까지 잃는 일이 되어서는 안 되며, 키 파일이 백업 대상 볼륨 위에 살면 정확히 그렇게 됩니다. 이 분리는 의도적으로 시험합니다. 원본을 본 적 없는 호스트에서, 계획이 사용 가능하다고 말한 것만으로 복원합니다.
점검 4: 이 대상에 변경 감지가 성립하는가
암호화된 컨테이너는 대부분의 전송 도구에 하나의 크고 불투명한 파일로 보이므로, 평문의 작은 수정이 도구와 형식에 따라 큰 재읽기나 전체 재업로드를 부를 수 있습니다. restic이 문서화하듯 가변 크기 청크 분할과 중복 제거가 이를 줄일 수 있지만, 그것은 그 도구의 성질이지 암호화된 컨테이너 일반의 성질이 아닙니다.
가정하지 말고 측정합니다. 작고 무해한 변경 뒤에 첫 실행과 두 번째 실행을 비교하고, 전송된 바이트와 경과 시간을 모두 기록합니다. 실험하는 동안 정상임을 아는 백업을 남겨 두어, 시험이 유일한 복원 지점을 소모하지 않게 합니다.
마지막으로 의미 있는 유일한 시험으로 목록을 마칩니다. 원래 기계 없이 복원하는 것입니다. 복원한 컨테이너를 열거나, 고른 파일을 메타데이터와 함께 복원하고, 애플리케이션이나 사용자가 결과를 쓸 수 있는지 확인합니다. 이 시험에 답하지 못하는 빠르고 잘 암호화된 전송은 데이터의 사본이지 백업이 아닙니다.