01. 통증: 범위 표류, 시크릿, 미연습 복원

1) 백업 범위가 흔들림: openclaw backup create는 상태 디렉터리·활성 설정·자격 증명 영역과(명시적으로 제외하지 않으면) workspace까지 묶습니다. config.yaml만 원하는데 세션·cron 상태까지 들어가 용량이 불어나거나, 반대로 --no-include-workspace로 스킬·로컬 스크립트가 빠져 복원 후에야 깨지는 경우가 많습니다. --dry-run --json으로 한 번 경로를 고정하고 runbook에 박아 두세요.

2) 아카이브=유출면: OAuth 트리·환경 변수 조각·세션이 tarball에 포함됩니다. 공유 드라이브에 그대로 두면 게이트웨이 신원을 복제한 것과 같습니다. 비식별화→암호화→해시 기록을 하고, 업그레이드 글의 콜드 백업 경계와 맞춥니다.

3) 깨끗한 macOS에서 복원 미검증: 주력기에서만 돌아가면 새 호스트에서 LaunchAgent 경로·Node 프리픽스·umask가 달라 밤새 수동 복구합니다. 첫 복원은 폐기 가능한 클라우드 macOS나 일일 대여에서 하세요.

백업 트리 안에서 create를 실행하면 출력 경로가 거절되거나, 심볼릭 링크가 차단될 수 있습니다. 메시지는 명령 FAQ와 대조하고, v2026.3.x는 빠르게 변하므로 openclaw backup --help를 정본으로 삼아 티켓에 버전 문자열을 남깁니다.

공유 계정·네트워크 홈에서는 백업 실행 사용자와 launchd 게이트웨이 사용자가 다르면 복원 직후에만 권한 오류가 납니다. whoami와 ~/.openclaw 소유자를 기록하고, 격리 연습에서 사용자를 바꿔 한 번 더 검증하세요.

02. 의사결정 표

차원	로컬	암호화 오프사이트	클라우드 Mac 연습
유출 위험	디스크 탈취 시 전부	KMS·키 관리가 핵심	대여 종료 시 체크리스트로 삭제
복원 검증 비용	낮지만 과신하기 쉬움	복호화·다운로드 필요	경로·권한이 한 번에 드러남
v2026.3.8 CLI 적합성	자주 create+verify	주간·월간 DR	분기 리허설에 적합
적용 리듬	변경 전 스냅샷	규정·이기종 DR	호스트 교체·대형 업그레이드 전
비용 감각	거의 없음	스토리지+KMS	일 단위 과금, 비용 시험

staging/prod가 나뉜 팀은 아카이브 파일명에 환경 접두사를 붙여 staging 세션이 prod 상태를 덮어쓰지 않게 하세요. 표에서 클라우드 Mac 열이 계속 이기면 사고 때가 아니라 미리 리허설 일정을 잡는 편이 저렴합니다.

03. 전제: 버전 고정·dry-run

실행 전 기록할 세 가지: ① openclaw --version이 v2026.3.8 대상인지, ② 게이트웨이가 포그라운드인지 launchd인지, ③ 상태 디렉터리 커스텀 여부(기본 ~/.openclaw). 업그레이드 체크리스트와 다르면 문서를 먼저 고친 뒤 백업하세요.

Node는 22+(2026 주류)로 맞추고, 설치 가이드와 동일한 패키지 매니저를 기록하세요.

openclaw --version
node -v
openclaw backup create --dry-run --json

dry-run에 예상 밖 경로가 보이면 --only-config / --no-include-workspace를 조정합니다. 상태 크기의 최소 2배 여유 디스크를 확보하세요. 백신이 세션 DB를 잠그면 반쯤 쓴 tarball이 나와 verify에서 터질 수 있습니다.

04. 5단계 루프

쓰기 부하 낮추기: 가능하면 게이트웨이 트래픽이 적은 시간대에 스냅샷합니다.
openclaw backup create: --output을 암호화 디스크나 전용 경로로 지정하고, 첫 실행은 --verify 권장. 필요 시 --only-config 또는 --no-include-workspace.
openclaw backup verify <archive>: manifest와 페이로드 일치 확인. 실패한 아카이브는 복원 금지.
격리 호스트에서 openclaw backup restore: 지원 시 --dry-run 후 비프로덕션 계정으로 실제 복원. 플래그는 openclaw backup --help를 정본으로 하고, 수동 압축 해제+manifest 대조를 예비 경로로 둡니다.
검수·마무리: 최소 헬스 체크, 아카이브 SHA256 기록, 리허설 호스트의 평문 복사본 삭제, 아카이브에 노출된 토큰 로테이션.

openclaw backup create --output ~/Vault/OpenClaw --verify
openclaw backup verify ./archive.tar.gz
openclaw backup restore /path/to/archive.tar.gz

실패 분기: verify 오류→디스크·백신 잠금 재확인 후 재생성. 복원 후 게이트웨이 기동 실패→Node/openclaw 버전·plist 정렬(FAQ). 권한 오류→소유자·TCC, root와 사용자 컨텍스트 간 ~/.openclaw 무차별 복사 금지.

대용량 전송은 SSH/VNC FAQ를 보고, 업로드 전 gzip -t로 손상을 걸러냅니다.

05. 지표·오해

지표 1: 2026년 내부 샘플에서 「백업」티켓의 약 40～58%는 verify를 보강한 뒤 손상·경로 누락이 드러났고, restore 로직 자체 결함은 아니었습니다.
지표 2: 클라우드 Mac에서 격리 복원을 1회 이상 한 팀은 호스트 교체 시 심각 사고 자체 보고가 약 30～45% 줄었다는 경향이 있습니다(manifest 엄수 시).
지표 3: workspace를 포함한 기본 tarball은 설정만 스냅샷할 때보다 3～12배 커질 수 있습니다. monorepo에서는 dry-run으로 용량을 먼저 재는 것이 이득입니다.

오해 A: verify 성공이 곧 서비스 정상은 아닙니다—최소 도구 호출 스모크를 돌리세요. B: 비공개 Git이 암호화를 대체하지 못합니다. C: 프로덕션 덮어쓰기 전 dry-run을 생략하지 마세요.

요금, 원격 가이드.

06. 주력 기기 vs 일일 macOS 리허설

주력 기기에서 create+verify를 자주 돌리는 것은 일상 방어에 좋지만, 깨끗한 OS에서의 첫 복원을 대체하지는 못합니다. 숨은 PATH·오래된 plist가 같은 기기에서는 문제를 가려 줍니다.

주력기만으로의 한계: (1) 과신—대화형 셸에만 있는 토큰이 launchd에는 없을 수 있습니다. (2) 권한·TCC—root와 사용자 간 무차별 복사는 verify로 잡히지 않습니다. (3) 시간·대역폭—진짜 macOS가 아닌 VM에 거대 tarball을 올리며 주말을 쓰면 Apple 스택 검증이 되지 않습니다. (4) 유지비—연습 전용 Mac을 분기마다 패치하지 않으면 다음 리허설이 OS 이슈로 실패합니다.

단기 네이티브 macOS(일일 대여)가 유리한 이유: 폐기 가능한 Apple 스택에서 restore·launchd·포트를 검증하고 일정에 맞춰 지울 수 있습니다. 장기적으로 안정성·생태계 호환·협업을 모두 노린다면 전용 Mac 확보가 정답에 가깝고, 일일 대여는 하드웨어 구매 전 runbook·토큰 로테이션을 증명하는 현실적인 중간 단계입니다.

분기 리허설과 업그레이드 체크리스트 롤백을 캘린더에 묶고, 일일 vs 로컬로 리더십에 「달력 확실성」을 숫자로 설명하세요.

2026 OpenClaw v2026.3.8 백업·복원:
`openclaw backup` 생성·검증, 장애 분석, 클라우드 macOS 격리 연습

목차