☰

Linux 및 FreeBSD 모두에서 읽을 수 있는 암호화된 백업

tag-icon • tag-icon linux encryption freebsd disk-encryption
Linux 및 FreeBSD 모두에서 읽을 수 있는 암호화된 백업

나는 암호화된 Linux와 FreeBSD 컴퓨터를 가지고 있습니다(각각 LUKS와 geli). 암호화되어 두 컴퓨터 모두에서 읽을 수 있는 백업을 만드는 방법이 궁금합니다(컴퓨터 중 하나에 오류가 발생하면 다른 컴퓨터를 사용하여 데이터를 신속하게 복구할 수 있도록).

불행하게도 봇 LUKS와 geli는 각각의 시스템에 대해 서로 포팅된 적이 없는 커널 모듈인 것 같습니다. BSD/Linux 호환 파일 시스템에 대한 여러 가지 위협으로 판단하면 양쪽 모두에서 읽을 수 있는 암호화되지 않은 백업을 만드는 것은 충분히 어려운 것 같습니다(ext2는 분명히 이를 허용하는 파일 시스템에 대한 유일한 옵션입니다).

그래서 내 생각은 Geli 암호화된 외부 디스크를 읽고 쓸 수 있고 Linux의 LUKS 암호화 파일 시스템 내부의 암호화되지 않은 가상 ext2 볼륨으로 데이터를 전송할 수 있는 가상 FreeBSD를 Linux KVM에 설정하는 것이었습니다. 약). 그러나 이는 매우 복잡해 보이고 실제로는 올바른 방법이라고 느껴지지 않습니다.

더 좋고, 더 쉽고, 더 선호되는 방법이 있나요? 아니면 위에서 설명한 방법이 현재 가능한 최선의 선택입니까?

감사해요; 이 문제에 대한 어떤 의견이라도 감사드립니다.

답변1

몇 가지 가정을 세워보겠습니다. 정확하지 않다면 댓글을 달아주세요.

  1. 다양한 운영 체제와 잠재적으로 다른 플랫폼을 사용하는 시스템을 실행합니다.
  2. 2개의 머신과 Linux 및 FreeBSD의 경우에 대해 설명합니다.
  3. 귀하의 컴퓨터는 암호화된 파일 시스템을 사용합니다
  4. 데이터 백업을 생성하고 해당 백업도 암호화하기를 원하는 경우
  5. 아카이브에 기여하는 모든 플랫폼에서 암호화된 백업의 데이터에 액세스할 수 있기를 원합니다.

(암호화 형식을 구별하기 위해 주석이 추가됨)

당신은 살아남은 컴퓨터에서 다른 시스템 데이터에 액세스할 수 있기를 원한다고 언급했습니다. 한 가지 방법은 암호화되지 않은 백업을 로컬 시스템의 암호화된 파일 시스템에 저장하는 것입니다. 또 다른 방법은 암호화된 백업을 암호화되지 않은 파일 시스템의 로컬 시스템에 저장하는 것입니다. 암호화되지 않은 파일 시스템에 암호화된 백업을 저장하는 것이 좋습니다.

그러나 여담이지만 암호화된 백업에 대해서는 항상 우려가 있습니다. - 키를 다룰 때는 정말 조심해야 합니다. - 부분적인 손상으로 인해 일반적으로 전체 백업이 종료됩니다.

내 제안: 사용

하나 또는 여러 컨테이너에 대한 백업을 생성하려면 두 머신 모두 액세스할 수 있습니다.

LAN 내부에 모든 것을 유지하려면 다음을 수행할 수 있습니다.

  1. 암호화된 백업 "패키지"를 저장하기 위해 두 호스트 모두에 "백업" 파일 시스템을 만듭니다. 저장된 백업 "패키지"(브랙업에서는 이를 "청크"라고 함)가 암호화되므로 파일 시스템을 암호화할 필요가 없습니다.
  2. 예를 들어 NFS를 사용하여 이러한 파일 시스템을 내보내고 각각 다른 호스트에 마운트합니다.
  3. 백업을 생성할 때 이를 로컬 파일 시스템에 덤프하고 다른 호스트의 NFS 마운트 디렉터리에 미러링합니다. 이는 백업 파일의 인스턴스가 두 개 있으면 좋은 부작용이 있습니다.

이제 서버에 다음과 같은 파일 시스템이 있습니다.

Tux에서는 Linux 머신에서:

/dev/foo            /           # encrypted filesystem
/dev/bar            /tuxdump    # unencrypted filesystem, local backup
beastie:/daemondump /daemondump # NFS backup destination

beastie에서는 FreeBSD 머신에서:

/dev/flurb          /           # encrypted filesystem
/dev/baz            /daemondump # unencrypted filesystem, local backup
tux:/tuxdump        /tuxdump    # NFS backup destination

백업해야 하는 데이터의 양에 따라 모든 클라우드 공급자가 할 수 있는 오프사이트 컨테이너를 고려할 수도 있습니다. 저는 현재 오래된 것들이 Glacier로 노화되도록 S3 컨테이너를 구성하는 작업을 하고 있습니다. 이는 가격 측면에서 매우 유망해 보입니다.

답변2

이중성- 이 작업을 위한 훌륭한 도구로 암호화에 GPG를 사용합니다. 나는 그것을 한동안 사용하고 있으며 정말로 추천합니다.

대안으로 다음을 시도해 볼 수 있습니다.

  • 오브남- 새로운 프로젝트이지만 몇 가지 좋은 기능이 있습니다(ssh/scp를 통해 사용하는 경우 약간 느립니다).
  • 트림- 비밀번호로 암호화

답변3

TrueCrypt는 Linux와 FreeBSD 모두에서 작동해야 합니다. 나는 정기적으로 Windows에서만 TrueCrypt를 사용하고 FreeBSD Truecrypt를 직접 사용해 본 적이 없습니다. YMMV.

답변4

rsync다른 머신의 하드 드라이브에 있는 일반 파일을 사용하여 머신의 파일을 백업할 수 있습니다 . 어쨌든 로컬 암호화를 사용하면 로컬 시스템 암호화로 암호화되고 전송은 TLS로 보호됩니다. 업데이트는 빠르며 검증된 암호화 및 백업 메커니즘을 사용합니다.

신뢰할 수 없는 시스템에서 파일을 백업해야 한다면 일반 GPG가 나에게 적합했습니다. 저는 Python을 사용하여 일부 암호화 및 FTP 전송을 자동화했는데, 이미 2년 동안 잘 작동하고 있습니다.

관련 정보