Pritunl 백업: 제어 상태와 생성된 프로필

하나의 아카이브는 작동하는 Pritunl 배포를 복원하고, 다른 하나는 그 이미지만 복원합니다. 클라이언트 프로필, 호스트 구성 복사본, 상태 디렉터리의 tarball은 모두 백업처럼 보이지만 어느 것도 단독으로 Pritunl이 관리하는 조직, 사용자, 서버 정의를 되돌려 주지 않습니다. 차이는 소유권입니다. 상태의 일부는 데이터베이스에 속하고, 일부는 호스트에 속하며, 일부는 다시 생성된 출력입니다. 잘못된 계층을 선택하면 복원은 시작하고 수신하지만 아무것도 모르는 서버를 만듭니다. 이 비교는 세 계층을 분리하여 보관하는 아카이브가 복구 중인 장애와 일치하게 합니다.

두 객체는 백업처럼 보이고 서비스를 복원하는 것은 하나뿐

다운로드한 클라이언트 프로필에는 인증서, 키, 엔드포인트가 들어 있습니다. 그 한 장치에는 완전하지만 배포 기록으로는 쓸모가 없습니다. 조직도, 비활성화된 사용자도, 서버 경로도, 관리 계정도 담고 있지 않습니다. 프로필 폴더에서 복원하면 무엇에도 인증할 수 없는 클라이언트가 생깁니다.

호스트 구성 복사본도 마찬가지로 부분적입니다. /etc/pritunl.conf는 데이터베이스에 도달하는 방법을 포함한 호스트 수준 설정을 담고 있으며 VPN 객체 자체는 담고 있지 않습니다.

데이터베이스가 소유한 것과 호스트가 소유한 것

Pritunl은 서버 정의, 사용자, 조직, 키를 MongoDB에 보관합니다. 그 데이터베이스가 권위 있는 제어 평면이며 디스크에 생성된 모든 OpenVPN 파일은 그로부터 파생된 출력입니다. 생성된 파일을 직접 고친 변경은 다음 재생성까지 살아 있다가 사라지므로 런타임 파일 편집은 지속적인 수정이 아닙니다. 같은 규칙이 유효 경로와 인터페이스에도 적용됩니다. 그것들은 제어 평면이 만들어 낸 것을 설명하며, 만들어 내야 할 것을 설명하지 않습니다.

호스트는 더 작지만 이전할 수 없는 값 집합을 제공합니다. 그중 하나가 /var/lib/pritunl/pritunl.uuid, 해당 노드의 정체성입니다.

그 정체성은 클러스터에서 가장 중요합니다. 대체 호스트는 활성 노드의 UUID 복제가 아니라 자체 등록이 필요하며, 그렇지 않으면 둘이 같은 정체성을 두고 다툽니다. 각 호스트, 그 UUID, 그것이 가리키는 데이터베이스 사이의 매핑을 기록하십시오. 단일 데이터베이스 덤프는 어떤 호스트 설정이 어느 머신에 속했는지 설명하지 못합니다. 소프트웨어 버전과 공개 엔드포인트 이름도 같은 기록에 속합니다.

일관된 덤프를 만들고 디렉터리 복사본은 만들지 마십시오

서비스가 쓰는 동안 MongoDB 데이터 디렉터리를 복사하면 사용 가능한 데이터베이스를 이루지 못할 수 있는 파일이 생깁니다. 대신 데이터베이스가 지원하는 덤프 경로를 실제로 가진 토폴로지에 대해 실행하십시오:

mongodump --uri="mongodb://127.0.0.1:27017/pritunl" --out=/var/backups/pritunl/db
sudo tar czf /var/backups/pritunl/host.tgz /etc/pritunl.conf /var/lib/pritunl/pritunl.uuid

단독 호스트는 그 단순한 형태를 견딥니다. 복제 세트는 일관된 시점이 필요하고, oplog 기반 덤프에는 일반 덤프에 없는 요구 사항이 있습니다. 지원되는 절차는 MongoDB 버전과 토폴로지에 따라 달라지므로 데이터 디렉터리의 존재에서 추론하지 마십시오. 호스트 계층을 덤프 옆에, 같은 실행에서, 같은 타임스탬프로 보관하십시오.

필요해지기 전에 복원을 연습하십시오

아무도 복원해 본 적 없는 백업은 가설입니다. 서비스를 격리된 네트워크에 구축하고, 덤프를 복원하고, 호스트 파일을 되돌려 놓으십시오:

mongorestore --uri="mongodb://127.0.0.1:27017" --drop /var/backups/pritunl/db
sudo tar xzf /var/backups/pritunl/host.tgz -C /

그다음 프로세스가 아니라 객체를 확인하십시오. 로그인하고, 조직과 사용자가 있는지 확인하고, 알아볼 수 있는 서버 정의에 대해 테스트 클라이언트 하나를 시작하십시오. 주소와 정체성이 의도적이 될 때까지 복원된 호스트가 프로덕션 엔드포인트를 광고하거나 실제 연결을 받아들이지 못하게 하십시오. 여기서 아카이브에 실패한 머신에만 있던 자격 증명이 필요하다는 것도 알게 되므로 복구 자격 증명을 독립된 곳에 보관하십시오. 방금 잃은 호스트에 의존하는 복원은 복원 계획이 아닙니다.

마지막으로, 오래된 스냅샷은 오래된 결정을 복원한다는 점을 기억하십시오. 관리자가 덤프를 만든 뒤 정체성을 비활성화했다면 복원은 그것을 다시 활성화합니다. 복구 후 조정은 절차에 속하며, 나중 생각에 속하지 않습니다.