메인 콘텐츠로 건너뛰기

Data Relay Link Server 백업·복원·검증하기

완성 결과: 인증서·설정·보안 정책·관리 ID·서비스 포트 예약을 일관되게 백업하고 복원 후 실제 동작을 검증합니다.
운영 Server의 Restore는 상태 교체·접속 중단을 초래할 수 있습니다. 반드시 승인된 장애 복구 또는 유지보수 창에만 실행하세요. 운영 장비에서 단순 연습을 위해 Restore하지 마세요.

1단계 — 백업 전 상태 기록

실제 Data Relay Link CLI 캡처 — 제품 버전 조회: 설치 버전과 DRLink Server 역할을 확인합니다. 그림 1. 제품 버전 조회: 설치 버전과 DRLink Server 역할을 확인합니다. 제품 CLI 출력 예시; 일부 주소·호스트는 가렸습니다. Server 셸:
설치된 제품 버전, Managed Host ID, Remote Service 예약 포트, 접근 정책 모드를 기록합니다.

2단계 — 일관된 Server 백업 생성

실제 Data Relay Link CLI 캡처 — Server의 System 메뉴: 백업/복원 3번, 진단 5번, 버전 정보 8번을 선택합니다. 그림 2. Server의 System 메뉴: 백업/복원 3번, 진단 5번, 버전 정보 8번을 선택합니다. 제품 CLI 출력 예시; 일부 주소·호스트는 가렸습니다. Server REPL:
출력되는 실제 백업 파일 경로를 보존하고 암호화된 별도 저장소에 안전하게 보관합니다. PKI, 설정, 비밀값, 인벤토리, 정책 및 예약 정보를 하나의 정합성 있는 백업으로 다루어야 합니다. 활성 SQLite DB의 WAL 때문에 drlink.db 파일만 임의 복사하는 방식은 신뢰할 수 없습니다.

3단계 — 복원 전 백업 검사

Server 셸:
성공 기준: 아카이브 형식, 무결성, 호환성이 검증됩니다. 실패하면 Restore하지 말고 정상 백업을 확보합니다.

4단계 — 승인된 복구 시 Restore

복원 대상/버전/서비스 중단 영향을 담당자가 승인한 경우:
화면의 변경·확인 내용을 검토하고 진행합니다. 무조건 Yes를 입력하지 마세요. 실패하면 복구/롤백 결과를 기록하고 성공으로 처리하지 않습니다.

5단계 — 복원 후 Server와 Agent 확인

실제 Data Relay Link CLI 캡처 — 실제 Agent Diagnostics 발췌: 복구 후 Agent 런타임과 Server 연결을 점검합니다. 그림 3. 실제 Agent Diagnostics 발췌: 복구 후 Agent 런타임과 Server 연결을 점검합니다. 제품 CLI 출력 예시; 일부 주소·호스트는 가렸습니다. Server REPL:
각 Agent Host REPL:
불변 Managed Host ID, Remote Service ID와 예약 공인 포트가 보존되고 Agent가 재연결했는지 확인합니다. SSH 원격 접속 또는 APT 프록시를 사용해 실제 승인 트래픽 1건의 성공과 비허용 트래픽 1건의 명시적 DENY를 확인하세요. HEARTBEAT나 HEALTHY 표시만으로 애플리케이션 통신을 검증했다고 판단하지 않습니다.

장애 대응

  • 검증 실패: 파일을 복원하지 않고 오류 증거 및 호환 백업 확보
  • Agent 재연결 실패: 기존 신원과 관리 경로 점검 후 동기화; 무작정 재등록하지 않음
  • 정책이 달라짐: Revision과 기존 백업의 규칙 비교. Remote Access 정책 Reset은 초기 ALLOW 상태를 만들 수 있으므로 주의
  • HEALTHY인데 앱 실패: 외부 포트/NAT/내부 대상 서비스를 별도로 점검
추가 정보는 백업/복원 참조와 문제 해결을 확인하세요.

최신 동작 확인 — 2026-10-28

복원 당시 저장된 호스트 존재/프록시 건강 상태는 Agent의 새 검증이 필요합니다. Server의 현재 Remote Service 검증이 없으면 연결된 Agent도 재조정합니다. diagnostics/synchronize와 실제 통신을 확인하고 복원/rollback 실패 시 아카이브·오류 증거를 보존하세요. 현재 CLI 전체 목록 · MCP 호환성
마지막 수정일 2026년 10월 28일