최소 백업 묶음 · 비식별보내기 · Gateway 콜드 스타트 · 채널 전량 재연결
누가 어떤 문제를 겪는가: OpenClaw를 운영 또는 준운영에 올려 두었는데도 디스크 교체와 설정 오삭제와 키 순환 이후에 재현 가능한 복구 경로가 없을 때가 많습니다. 흔한 증상은 Gateway 프로세스는 떠 있으나 Slack과 Discord와 Telegram 같은 채널이 한꺼번에 끊기거나 조용히 실패하는 형태입니다. 이 글이 주는 결론: 최소 백업 묶음과 비식별보내기 꾸러미와 콜드 스타트 검사 순서와 채널 한 줄 대조표로 RTO와 RPO를 표어가 아니라 티켓 필드에 적을 수 있는 문장으로 내립니다. 가져갈 것: 다섯 가지 재해복구 위험 범주, 백업에 넣을 것과 넣지 말 것 표, 비식별보내기 여섯 단계, Gateway 콜드 스타트 여섯 단계 런북, 메신저 측과 Gateway 측 대응 표, 분기 훈련 기록 템플릿이며 지속 가능 업그레이드와 세 채널 장문과 런타임 장애와 프로덕션 강화 장문과 상호 링크합니다.
01업그레이드 롤백 문서가 다루는 축은 버전과 포트 충돌이고 재해복구가 다루는 축은 신원과 외부 시스템과의 관계가 사라진 뒤입니다. 저장소만 백업하고 Gateway 경계와 작업 공간 경계를 빼면 복구 뒤에는 모델 호출은 되는데 채널이 말을 잃는 그림이 납니다. 반대로 전체 로그와 비밀을 공유 드라이브에 그대로 넣으면 규정 준수와 사고 대응 양쪽에서 발등을 찍습니다. 지속 가능 업그레이드와 백업 고정을 함께 읽을 때는 업그레이드 직전 백업을 고빈도 작은 집합으로, 재해복구 훈련을 저빈도 전체 집합으로 두는 것이 정리에 도움이 됩니다. 전자는 일상 변경을 받고 후자는 재난 가정을 받습니다.
두 번째 위험은 경로 드리프트입니다. 복구 호스트에서 홈 경로와 데몬 레이블과 이전 기기 이름이 어긋나면 파일은 찾았는데 서비스 단위에 걸리지 않는 상태가 됩니다. 세 번째는 채널 비밀과 콜백 URL이 쌍으로 깨지는 경우입니다. 메신저 플랫폼 측 토큰은 살아 있어도 공개 입구나 TLS 인증서가 바뀌면 Gateway 로그에는 콜백 오류가 쏟아지는데 원인을 모델 할당량으로 오판하기 쉽습니다. 네 번째는 이중 설치와 PATH 오염으로 콜드 스타트 때 오래된 바이너리를 끌어올려 새 설정과 반쯤만 맞는 조합을 만드는 일입니다. 다섯 번째는 훈련을 실제로 돌려 보지 않은 경우입니다. 런북은 문서 라이브러리에만 있고 교체 기기 앞에서는 필수 필드와 담당자 시간 창이 비어 있는 장면이 반복됩니다. 운영팀이 분기마다 동일한 스크립트를 재사용하려면 티켓 시스템에 스냅샷 이름과 복구 담당과 검증 채널을 고정 필드로 박아 두는 편이 안전합니다.
현장에서는 위 범주가 겹쳐 단일 라벨인 네트워크 문제로 접히기도 합니다. 그래서 첫 질문을 대역폭이 아니라 신원과 경로와 단일 리스너 여부로 고정하는 습관이 필요합니다. 회의에서 합의만 하고 필드 이름을 바꾸지 않으면 다음 분기에 같은 논쟁이 재생됩니다.
Git만 백업하고 Gateway 경계는 빼는 경우: 복구 뒤에는 빌드는 되는데 메시지를 받지 못하며 세 채널 장애 분류와 증상은 비슷하지만 뿌리는 설정 면 결손에 있습니다.
비밀을 평문으로 티켓에 붙이는 경우: 최소 노출 원칙을 깨고 감사에서 걸립니다.
로그를 통째로 복제하는 경우: 용량과 프라이버시가 동시에 터지므로 보존 창과 필드 화이트리스트를 먼저 정의합니다.
데몬 이름과 launchd 또는 systemd 유닛을 무시하는 경우: 프로세스는 있는데 헬스 검사만 실패하는 그림이 납니다.
훈련 후 스냅샷으로 되돌리지 않는 경우: RPO가 실제로 성립했는지 검증할 수 없습니다.
| 대상 | 재해복구 꾸러미 권고 | 이유 요약 |
|---|---|---|
| Gateway 설정과 버전 고정 | 포함 | 수신면과 라우팅과 채널 바인딩을 결정하며 업그레이드 글과 필드 이름을 맞춥니다 |
| 장기 API 비밀과 봇 토큰 | 포함하되 암호화 저장소 | 복구 뒤 신원을 증명해야 하며 평문 첨부는 금지입니다 |
| 작업 공간과 AgentSkills 경로 | 포함하되 구조와 해시 | 프로덕션 강화 스킬 감사 필드와 맞춥니다 |
| 전체 접근 로그 | 기본 제외 | 샘플 창과 비식별 규칙을 먼저 둡니다 |
| 임시 다운로드 디렉터리 | 제외 | 재생 가능하며 실을수록 유출면이 커집니다 |
재해복구 꾸러미의 목표는 전체 컴퓨터를 복제하는 것이 아니라 깨끗한 기기에서 동일한 외부 계약을 다시 세우는 것입니다.
비식별은 보기 좋게 가리는 일이 아니라 온콜이 노출면을 넓히지 않고 문제를 재현할 수 있게 만드는 일입니다. 런타임 장애 분석에서 말한 최소 재현 꾸러미와 같은 축입니다. 버전과 채널 유형과 오류 코드 발췌와 시간선은 복원 가능해야 하며 전체 웹훅 시크릿과 사용자 쪽지 내용은 복원 가능하면 안 됩니다. 아래 여섯 단계는 보내기 전 자가 점검 순서이며 변경 관리 필수 입력으로 넣는 것을 권합니다.
운영 조직이 커질수록 동일한 스크립트를 여러 팀이 각자 복제해 필드 이름만 다른 보내기가 생깁니다. 상위 디렉터리 이름과 타임스탬프 접두와 보존 기한 문장을 표준화하면 감사 대응이 짧아집니다. 법무와 보안이 요구하는 파기 시각은 티켓 본문 한 줄에 박아 두는 편이 이후 분쟁을 줄입니다.
버전 사각형 고정: CLI 버전과 Gateway 빌드 식별자와 Node 런타임과 운영체제 패치 수준입니다.
채널 열거: 켜 둔 채널과 각각의 마지막 성공 콜백 시각을 적되 토큰 본문은 넣지 않습니다.
설정 구조 요약: 트리 경로로 핵심 파일 존재만 나열하고 민감 값은 자리 표시자로 둡니다.
오류 발췌: 최근 N줄 중 채널 또는 TLS와 관련된 줄만 고정 바이트 상한으로 자릅니다.
네트워크 판정: 출구 IP와 인증서 지문과 리버스 프록시 규칙 버전이 해당되면 함께 적습니다.
책임자와 시간 창: 누가 이번 보내기를 승인했는지와 파기 예정 시각을 적습니다.
절대 금지: Slack 서명 비밀과 Discord 봇 토큰과 Telegram 봇 토큰을 공유 드라이브나 메신저 붙여넣기에 평문으로 넣지 마십시오. 암호화 저장소나 플랫폼 측 순환 절차로 대체합니다.
콜드 스타트 순서는 다중 플랫폼 설치와 데몬 글과 맞추는 것이 좋습니다. 먼저 Gateway 리스너가 하나인지 확인한 뒤 채널 이야기를 합니다. 각 단계마다 합격과 불합격 판정이 있어야 하며 불합격일 때 곧바로 재설치로 건너뛰기보다 증거 표로 되돌아가 PATH와 유닛 파일과 포트 점유를 가릅니다.
훈련일과 실제 장애일의 차이는 심박수뿐 아니라 동시에 열린 티켓 수입니다. 그래서 doctor 출력을 스크린샷으로 흩뿌리기보다 티켓 색인 필드에 붙일 수 있는 텍스트 블록으로 모으는 규칙을 두면 교대가 빨라집니다. VPN이 켜진 채로 바인딩 면만 바뀌는 사례는 로그만으로는 희미하므로 인터페이스 이름과 예상 주소를 같은 줄에 적는 습관이 필요합니다.
설치면이 하나인지 확인: which 결과와 패키지 관리자 전역 경로를 맞대보고 이중 설치를 제거합니다.
데몬을 올리고 유닛 이름을 기록: launchd 또는 systemd 레이블을 설치 글과 대조합니다.
바인딩 면 점검: 수신 주소가 의도한 인터페이스에 있는지와 VPN이나 방화벽이 바꿨는지 봅니다.
헬스와 doctor 계열 명령: 출력을 티켓 색인 필드에 넣고 스크린샷만 남기지 않습니다.
최소 채널 프로브: 전량 재연결 전에 한 채널만으로 먼저 변수를 줄입니다.
시간 동기와 TLS 체인: 시계 어긋남과 중간 인증서 만료는 콜드 스타트에서 자주 나는 원인입니다.
export OC_EXPORT_DIR="./openclaw-drill-$(date -u +%Y%m%d%H%M%SZ)"
mkdir -p "${OC_EXPORT_DIR}/redacted"
openclaw version > "${OC_EXPORT_DIR}/version.txt" 2>&1
openclaw gateway status > "${OC_EXPORT_DIR}/gateway-status.txt" 2>&1 || true
openclaw channels status > "${OC_EXPORT_DIR}/channels-status.txt" 2>&1 || true
tar -czf "openclaw-drill-bundle.tgz" "${OC_EXPORT_DIR}"
안내: 예시 명령은 상태 텍스트만 모읍니다. 환경에 맞게 보안 검토를 거친 보내기 스크립트로 바꾸고 tar 꾸러미 권한을 제한하십시오.
복구 뒤 Gateway 헬스는 통과하는데 메시지가 돌아오지 않는 경우는 대개 콜백 도달성이나 권한 범위 변경에 가깝고 모델 라우팅과는 거리가 있습니다. 아래 표는 트리아지 때 최소로 맞춰 볼 필드 집합이며 세부 단계는 세 채널 접속과 장애 분류로 돌아가 실행합니다. 콜백 TLS를 확인하기 전에 모델 비밀만 반복 순환하지 않도록 순서를 지킵니다.
팀이 다중 모델 티어와 예비 라우팅을 동시에 쓰면 채널 복구 전에 모델 단계로 점프해 원인을 잘못 묶는 일이 생깁니다. 채널이 안정된 뒤에 티어를 바꾸는 규칙을 런북 첫 페이지에 두면 논쟁이 줄어듭니다. 해당 필드는 다중 모델 라우팅 장문과 맞춥니다. 전량 재연결이 끝나면 테스트 메시지 수신부터 첫 도구 호출 성공까지 걸린 시각을 한 번 남겨 분기 훈련 기준선으로 씁니다.
| 채널 | 메신저 측 필수 확인 | Gateway 측 필수 확인 |
|---|---|---|
| Slack | 앱 권한 범위와 이벤트 구독 URL과 서명 비밀 버전 | 콜백 라우팅과 TLS 인증서 체인과 출발 화이트리스트 |
| Discord | 인텐트와 봇 가시 범위와 게이트웨이 URL | 웹소켓 업그레이드 경로와 리버스 프록시 시간 제한 |
| Telegram | 웹훅 모드와 인증서 업로드와 허용 IP | 공개 입구 포트와 NAT 세션 유지 |
표의 각 칸은 티켓 한 줄로 접을 수 있게 짧게 잘랐습니다. 현장에서는 칸마다 증거 링크를 한 개씩만 걸어도 교대가 따라오기 쉬워집니다.
아래 세 줄은 착수 전에 맞춰 볼 경험치이며 숫자는 팀의 실제 훈련 데이터로 바꾸십시오. RTO는 재난 선언부터 첫 채널이 테스트 메시지를 받을 때까지의 시간이고 RPO는 잃어도 되는 설정 변경 창으로 변경 관리 도구의 기록 단위와 맞춥니다.
RTO 논의만 길어지고 RPO는 한 줄도 없는 계획서가 많습니다. 두 축을 같은 표에 두지 않으면 분기마다 한쪽만 개선한 척하는 보고가 나옵니다.
| 조직 규모 | 규정 요구 | 훈련 빈도 | 우선 선택 |
|---|---|---|---|
| 개인 개발자 | 표준 | 반기 | 암호화 백업 꾸러미와 단일 기기 콜드 스타트 스크립트 |
| 작은 팀 | 표준 | 분기 | 이인 검토와 채널 프로브 목록과 티켓 필드 틀 |
| 플랫폼 팀 | 높음 | 월별 탁상 훈련과 분기 실기 | 분할 비밀 저장소와 자동 보내기와 감사 색인 |
순수 로컬 노트북은 디스크와 절전과 시스템 업데이트 창 때문에 안정적인 RTO를 맞추기 어렵고 자가 호스팅 서버는 TLS와 백업과 채널 콜백을 팀이 모두 짊어집니다. 비교적 계약서에 적을 수 있는 클라우드 Mac 노드는 가용성 조항과 리전 선택을 조달 부속에 넣기 쉽고 Gateway 상주를 개인 기기 운에 맡기지 않고 서비스 등급 논의로 올립니다.
흔한 오해: 훈련에서 프로세스만 기동되는지 보고 외부 메시지 수신은 보지 않는 경우입니다. 외부 계약이 곧 OpenClaw의 생산 가치입니다.
팀이 OpenClaw 재해복구와 감사 가능한 채널 복구를 동시에 원하면 개인 기기와 임시 빌린 머신은 키 순환과 공개 입구 안정성에서 계속 빚이 남습니다. 생산급 Gateway 상주와 재현 가능한 훈련을 함께 잡아야 할 때 VpsMesh Mac Mini 클라우드 임대가 실무에서 더 나은 경우가 많습니다. 주기 과금과 리전 선택과 전용 감사 가능 노드로 재해복구 논의를 실제 네트워크와 가용 데이터 위에 두지 말로만 두지 않게 합니다. 규격과 주기 비용은 가격 페이지에서, 계약과 지원 경로는 고객 센터에서, 리전과 구성 확정은 주문 페이지에서 한 번에 맞추면 검토 회의가 짧아집니다.
업그레이드 문서는 버전 채널과 포트 충돌을 다루고 재해복구 문서는 전체 장애와 디스크 손상과 오삭제 이후 최소 복구 집합과 채널 전량 재연결 순서를 다룹니다. 함께 읽을 때 지속 가능 업그레이드 장문을 먼저 고정합니다. 규격과 발주는 주문 페이지에서 확인합니다.
버전 사각형과 채널 열거와 설정 경로 요약과 오류 발췌와 시간선입니다. 장기 비밀은 평문으로 넣지 않습니다. 플랜 비교는 가격 페이지에서 합니다.
먼저 Gateway 헬스와 바인딩 면을 확인한 뒤 세 채널 장애 분류로 메신저 측과 Gateway 측을 맞춥니다. 연결과 절차는 고객 센터에서 보완합니다.