제21장 백업 및 복구: 컴퓨터가 초기화되어도 안심하기

클라우드 컴퓨터가 초기화되면 환경이 완전히 비워지며, 기억에만 의존해 apt-get과 pip install을 입력하다 보면 의존성이나 환경 변수를 빠뜨리기 쉽고, 튜닝한 Bot의 기억 역시 내보내기 버튼이 없습니다. 해결책은 재해 복구를 두 개의 병렬 파이프라인으로 나누는 것입니다.

1. 가상 머신 서비스: 등록 원장과 자동 복구 스크립트로 시스템 의존성을 인계받습니다.
2. 에이전트 기억: 전담 기억 관리자가 설정과 동적 사실을 Markdown으로 작성하여 프라이빗 Git 저장소에 푸시합니다.

구축을 완료하면 시스템이 초기화되거나 마이그레이션되더라도 최소한의 수동 개입만으로 모든 서비스와 기억을 다시 불러올 수 있습니다.

21.1 클라우드 컴퓨터의 실체 파악하기: 업데이트, 복구, 초기화의 차이점

동일 계정의 모든 Bot은 동일한 가상 머신을 공유하며, /workspace 디렉터리와 시스템 프로세스를 함께 사용합니다. 한 머신에 전역 도구를 설치하면 다른 Bot도 모두 호출할 수 있지만, 머신이 한 번 초기화되면 모든 의존성 환경이 동시에 무효화됩니다.

《4.6 가상 머신, 기억 및 백업》을 참고하세요.

클라이언트는 Settings > 컴퓨터의 Bot's 컴퓨터 아래에서 제어 항목을 제공합니다. 세 가지의 차이점은 다음과 같습니다:

작업	메커니즘	유지되는 내용	손실되는 내용
업데이트(Update)	환경 이미지를 업그레이드합니다. 소프트웨어 업데이트와 컴퓨터 업데이트 두 종류로 나뉩니다	소프트웨어 업데이트는 전체 유지; 컴퓨터 업데이트는 봇, 파일 및 로그인 정보 유지	소프트웨어 업데이트는 손실 없음; 컴퓨터 업데이트는 전역 애플리케이션 및 패키지 제거
Recover	저장된 데이터를 기반으로 최신 이미지에서 새 머신을 생성하며, 먼저 기존 머신에 연결하여 데이터 저장을 시도합니다	저장된 봇, 파일 및 로그인 정보	전역 애플리케이션 및 패키지; 이전 머신에 연결할 수 없는 경우 동기화되지 않은 수정 사항 손실
Reset	가장 최근에 저장된 데이터를 기준으로 즉시 새 머신을 생성하며, 실행 중인 작업을 중단합니다	저장된 봇, 파일 및 로그인 정보	전역 애플리케이션 및 패키지; 동기화되지 않은 수정 사항 손실

대화 기록은 클라우드에 저장되므로 머신이 초기화되거나 실수로 파일을 삭제해도 영향을 받지 않습니다. 하지만 전역으로 설치된 애플리케이션 패키지, node_modules 및 Python 가상 환경은 공식적으로 저장되지 않으며, 컴퓨터 업데이트, Recover 또는 Reset 시 모두 제거됩니다.

자세한 내용은 《Grok Bot 컴퓨터》를 참고하세요.

가상 머신이 멈추거나 응답에 이상이 있을 때는 순서대로 문제를 해결해야 합니다:

1. Reconnecting 또는 Couldn't Reach Grok Bot's 计算机 표시: 네트워크 변동에 해당하므로 잠시 기다린 후 Retry를 클릭합니다. 재연결 중에는 파일이 손실되지 않으므로, 이 단계에서는 절대로 Reset을 클릭하지 마세요.

2. 클라이언트 재시작. Mac 사용자는 상단 메뉴 모음에서 반드시 Quit을 선택해야 하며, 창의 빨간색 닫기 버튼을 누르는 것만으로는 적용되지 않습니다.

3. 업데이트 확인. Settings > 컴퓨터로 이동하여 사용 가능한 업데이트가 있으면 먼저 업데이트를 클릭합니다. 에이전트가 일시 중지되지 않았다는 안내가 나타나면 현재 작업이 끝날 때까지 기다린 후 클릭합니다.

4. 복구 시도. 여전히 연결되지 않거나 업데이트가 멈춰 컴퓨터 복구가 나타나면 Recover를 클릭합니다. 만약 Update 仍在运行(업데이트 실행 중)이라는 안내가 표시되면 Keep waiting을 선택합니다.

5. Reset 실행. 앞의 네 단계가 효과가 없을 때 Reset을 클릭합니다. 실패 시 Retry Recover 또는 Retry Reset으로 재시도하고, 계속 오류가 발생하면 공식 지원팀에 문의하세요.

6. 디스크 경고 처리.

   Computer is low on disk space 또는 Computer is critically low on disk space 경고를 받더라도 수동으로 파일을 삭제하지 말고, 사이드바의 Go to Disk Saver를 클릭하여 방안을 확인하세요. 사용자의 확인 없이는 시스템이 임의로 파일을 삭제하지 않습니다.

   자세한 내용은 《Grok Bot 컴퓨터》를 참고하세요.

클라우드 컴퓨터는 일회용 컨테이너에 불과하므로, 환경을 수동으로 미세 조정하지 마세요. 구축 과정은 모두 스크립트화하고, 설정 및 자체 작성 소스 코드는 반드시 외부 프라이빗 Git 저장소에 보관해야 합니다.

21.2 가상 머신 서비스 원장과 자동 복구 파이프라인

《4.6 가상 머신, 기억 및 백업》

클라우드 컴퓨터는 저수준 스냅샷을 제공하지 않으므로, 재구축 프로세스를 원클릭 스크립트로 만드는 것이 비용이 가장 적게 듭니다.

서비스 원장과 오염 방지 백업

프라이빗 저장소에 vm-services/ 디렉터리를 만들고, 사람이 읽는 REGISTRY.md 표와 자동화 스크립트가 파싱하는 registry.json을 배치합니다.

원장과 백업에는 몇 가지 엄격한 규칙을 지켜야 합니다.

• 등록 필드에는 서비스 ID, 담당 Bot, 코드 경로, 설치 의존성(apt/pip/Docker/cron), 시작/중지 및 상태 확인 명령어, 필수 복구 여부 등이 포함됩니다.
• 인증 정보 경로는 로컬 절대 경로(예: ~/.env)만 작성하고, 평문 저장은 엄격히 금지합니다. QR 코드 스캔 및 OAuth 등 수동 작업 단계는 별도로 강조 표시합니다.
• 자체 작성 스크립트는 service-src/에 별도로 저장하고, venv/, node_modules/ 및 로그는 제외합니다. 커밋 전에는 반드시 정규식으로 비밀 키를 스캔해야 합니다.

자동 복구 파이프라인

vm-services/restore/ 아래에 각 서비스별 하위 스크립트를 따로 작성합니다. 스크립트는 반드시 멱등성을 보장해야 하며, 두 번 연속 실행해도 디렉터리가 이미 존재한다거나 포트 충돌이 발생하는 등의 오류가 없어야 합니다.

메인 엔트리인 restore-all.sh는 의존성 순서에 따라 순차적으로 실행합니다.

1. 기본 의존성: cron, ffmpeg, yt-dlp 등 시스템 도구를 설치합니다.
2. 소스 코드 배치: service-src/에서 자체 작성 스크립트를 복사해 오며, 이미 존재하는 파일은 건너뛰고 누락된 부분만 보충합니다.
3. 환경 및 패키지: Python 가상 환경을 생성하고 pip install -r requirements.txt를 실행합니다.
4. 상주 프로세스 실행: 백그라운드 상주 프로세스를 시작합니다.
5. 예약 작업 등록: 통합된 crontab 스케줄을 복구합니다.
6. 상태 확인: 각 항목의 정상 동작 여부를 하나씩 확인하며, 실패 시 오류 로그를 기록하고 다음 항목으로 계속 진행하여 전체 프로세스가 차단되지 않도록 합니다.

《Grok Bot 가상 머신 초기화 후 도구가 모두 사라졌다면? 백업 및 복구 튜토리얼 (프롬프트 포함)》

21.3 기억 관리자: Bot의 핵심 기억을 프라이빗 저장소에 담기

공식적으로 전체 기억 내보내기 버튼을 제공하지 않기 때문에 계정을 바꾸거나 시스템을 이전할 때 설정이나 선호 사항을 잃어버리기 쉽습니다. 전담 '기억 관리자' Bot을 두고 무형의 기억을 프라이빗 Git 저장소의 일반 텍스트 스냅샷으로 변환하는 것이 가장 안전합니다.

《Grok Bot 百万撤离：一套完善的 Agent 系统备份方案》

기억 계층화 및 유지 관리 원칙

계층	포함 내용	설명 및 권한
공유 계층	계정 공유 기억, 공용 Skill 및 플러그인 설정	모든 Bot 읽기 가능
전용 계층	Description 규칙 계약, 전용 독립 기억 및 Routine 작업	단일 Bot 독점

• 동적 사실은 컨텍스트에 장기적으로 쌓아두지 않고 접근 방식만 기록해 두었다가 필요할 때 원본에서 가져옵니다.
• 공용 기억은 교차 오염을 방지하기 위해 수동 검토나 표준화된 비즈니스 워크플로 검증을 거쳐야 합니다.
• 비즈니스 정의는 기억에 기록하고, 고정된 작업 절차는 반드시 Skill 코드에 확정해 넣어야 합니다.

《4.6 가상 머신, 기억 및 백업》

아카이빙 규격 및 워크플로

아카이빙 규격 및 워크플로

├── bots/                     # 各 Bot 独立配置与记忆
│   ├── cyber-xiaowan/        # 单个 Bot 文件夹
│   │   ├── agent-spec.md     # 身份设定、名称、bot-id、slug、description
│   │   ├── MEMORY.md         # 核心记忆全量快照
│   │   ├── profile.md        # 角色信息与权限边界
│   │   └── archive/          # 历史版本与过往日志
│   └── ...                   # 其他 Bot 目录
├── meta/                     # 全局元数据与多 Bot 拓扑关系
├── shared-user-memory/       # 账号级共享记忆
├── vm-services/              # 虚拟机服务总账与恢复脚本（见 21.2 节）
├── README.md                 # 仓库使用说明与最新状态
├── RESTORE.md                # 跨环境恢复操作 SOP
└── registry.md               # 登记索引

개별 Bot 디렉터리 아래의 MEMORY.md에는 신원 및 권한, 의사결정 책임, 현재 현장 스냅샷의 3개 계층이 포함됩니다.

1. 명단 열거: 영구 백업이 필요한 핵심 Bot을 지정합니다.
2. 명령 스케줄링 및 하달: 각 Bot이 자신의 설정과 기억을 읽고 정제한 후 /workspace의 해당 Markdown 파일에 작성합니다.
3. 수집, 검증 및 저장소 커밋: 스캔을 통해 평문 Token이 없음을 확인한 후 일괄 커밋하고, 날짜 태그(예: tag-2026-10-15)를 지정하여 원격 프라이빗 저장소로 푸시합니다.

Bot은 전체 스냅샷을 담당하고, Git은 증분 추적을 담당합니다. Bot은 매번 파일을 전체 덮어쓰기로 직접 작성하고, 이전 변경 내역은 Git 엔진이 축적하도록 하므로 프롬프트 내에서 차이점을 계산할 필요가 없습니다.

21.4 실战 사례: 铁柱AGI 의 백만 철수와 서비스 관리자

기억 관리자 백업

铁柱（@cgnot996）는 21개의 Bot을 직접 관리하고 있습니다. 계정 정지로 기억을 잃는 것을 방지하기 위해 그는 '기억 관리자' Bot을 구축하고 Gitee 프라이빗 저장소에 아카이빙하도록 설정했습니다.

1. 핵심 선정: 21개 Bot 중 먼저 7개의 핵심 Bot을 골라 시범 운영했습니다.
2. 내보내기 및 대조: 7개 Bot에 설정과 기억을 내보내도록 통지했습니다. 일부 Bot은 내보내기를 완료한 후 아무런 응답을 하지 않으므로, 지시어에 반드시 '작성 완료 후 보고할 것'을 요구하고 관리자가 /workspace 디렉터리를 스캔하여 대조해야 합니다.
3. 저장소 커밋 및 태그 지정: 첫 번째 73KB 분량을 아카이빙하여 커밋하고, tag 2026-09-10 태그를 부여한 후 비밀 키 스캔을 통과했습니다.
4. 단일 아카이브 구조: '사이버 샤오완'의 경우, MEMORY.md(약 21KB)에 신원과 스냅샷을 저장하고 agent-spec.md에 bot-id와 설명을 저장했습니다.
5. 정기 작업 활성화: 정기적으로 자동 아카이빙되도록 설정했습니다.

새 계정으로 가져올 때 기억 복원율은 약 80%입니다. 로컬에 백업되지 않은 파일, 대화 기록 및 서드파티 로그인 상태는 복원할 수 없습니다.

Hermes 또는 OpenClaw로 마이그레이션할 때는 MEMORY.md를 기억 디렉터리에 넣고, agent-spec.md의 description을 시스템 프롬프트로 변경하면 바로 실행할 수 있습니다.

《Grok Bot 百万撤离：一套完善的 Agent 系统备份方案》

가상 머신 서비스 관리자

클라우드 컴퓨터가 다운되어 초기화되면 도구를 모두 잃게 됩니다. 작성자는 Gitee grok-bot-memory 저장소의 vm-services 디렉터리에 재구축 원장을 기록했습니다.

1. 원장 등록: 2026-10-10 기준으로 10개 Bot의 20개 프로젝트(상주 서비스 4개, 온디맨드 도구 14개, 비밀 키 항목 2개)를 등록했으며, 그중 18개 항목을 '필수 복구'로 표시했습니다.
2. 서비스 분류: 상주 서비스에는 크롤링 서비스, Muse 인터페이스 래핑, 이메일 엔진 및 아웃바운드 터널이 포함되며, 온디맨드 도구(ffmpeg, Chrome 등)는 설치 명령만 기록하고, Metaso 및 TikHub는 비밀 키 경로만 기록했습니다.
3. 소스 코드 클린 백업: 자체 작성한 소스 코드는 약 5.1MB로, 비밀 키, 로그 및 상태 스트림은 제외했습니다.
4. 연계 복구: 관리자가 restore/ 디렉터리와 restore-all.sh를 유지 관리합니다. 관리자는 평소에 임의로 실행하지 않으며, 사람의 지시를 기다린 후 의존성에 따라 기동하고 검수 체크리스트를 제출합니다.

《Grok Bot 虚拟机重置后工具全没了？备份恢复教程（附提示词）》

21.5 자격 증명 보안 및 수동 승인 게이트: 화면은 넘겨도 비밀번호는 넘기지 않는다

여러 Bot이 가상 머신의 디스크와 브라우저 세션을 공유하므로, 단순히 새 Bot을 만드는 것만으로는 민감한 데이터를 격리할 수 없습니다. 스크립트나 대화에 평문으로 작성하면 다른 Bot이나 외부 로그에서도 모두 읽을 수 있습니다.

《4.6 가상 머신, 기억 및 백업》

자격 증명은 경로만 남기고 평문은 남기지 않기

• Token과 개인 키는 Git에 포함되지 않는 ~/.env 또는 전역 키 디렉터리에 저장합니다.
• REGISTRY.md, registry.json 및 기억 파일에서는 자격 증명과 관련된 부분은 디스크의 절대 경로만 기록합니다.
• 대화창에 비밀번호를 전송하는 것은 엄격히 금지되며, 푸시하기 전에 반드시 정규식 마스킹 스캔을 실행해야 합니다.

화면은 넘겨도 비밀번호는 넘기지 않는다

1. Bot이 2FA, QR 코드 스캔 또는 디바이스 인증 팝업을 만나면 즉시 작업을 일시 중지하고 사용자에게 인계를 요청합니다.
2. 사용자가 클라이언트에서 클라우드 컴퓨터 전체 화면을 열고 직접 비밀번호를 입력하거나 QR 코드를 스캔합니다.
3. 완료 후 제어권을 다시 넘겨주면, Bot은 세션 Cookie를 상속받아 계속 실행되며 평문 비밀번호에는 접근하지 않습니다.

고위험 작업에 Ask-first 설정

• 게시물 등록, 결제, 데이터 삭제 또는 기본 환경 수정 등 되돌릴 수 없는 작업은 반드시 팝업을 띄워 사람의 승인을 받아야 합니다. v0.70.2에서 이러한 확인 로직이 개선되었습니다.
• Bot의 자율 권한은 읽기, 공개 검색 및 /workspace 내부 읽기/쓰기로만 제한되며, 규칙이 충돌할 때는 Ask-first가 우선합니다.

21.6 바로 복사해서 쓸 수 있는 프롬프트 3선

다음은 실전 검증을 거친 세 가지 프롬프트로, 해당하는 Bot에 그대로 복사하여 전송하면 배포 및 사용할 수 있습니다.

프롬프트 1: 클라우드 컴퓨터에 '가상 머신 서비스 관리자' 설정하기

'가상 머신 서비스 관리자' Bot을 만들고 설정에 붙여넣습니다:

提示词一：给云电脑配置「虚拟机服务管家」

你是「虚拟机服务管家」，只管一件事：记下这台虚拟机上部署过的所有第三方服务，并在电脑更新或换账号之后，按记录把它们原样恢复。

你维护的东西
1. 一份登记总账，人和机器各读一份：REGISTRY.md（表格）和 registry.json（给脚本读）。
2. 每个服务一个恢复脚本 restore/restore-<服务>.sh，必须幂等，重复跑也不会出错。
3. 一个总入口 restore/restore-all.sh，按依赖顺序调用各个恢复脚本，最后汇总哪些失败了。
4. 一份源码备份 service-src/：各 Bot 自己写的服务代码和脚本，同步时排除密钥、日志、运行状态、虚拟环境和个人数据，并先扫一遍明文密钥，命中就停。
5. 以上全部跟着一个私有 Git 仓库存（「你的备份仓库地址」）。总账、恢复脚本、源码都在仓库里，密钥永远不进仓库。

登记规则（其他 Bot 部署任何服务都必须来找你登记）
每项必须包含：
- 名称和短 id、用途、负责的 Bot
- 路径：代码、配置、数据分别在哪
- 安装方式和依赖（apt / pip / npm / Docker / 系统定时任务）
- 启停命令、健康检查命令
- 更新后的恢复步骤，或者对应的恢复脚本
- 是否必恢复：是 / 否
- 密钥：只写存放路径，绝不写明文
- 需要真人完成的步骤（OAuth 登录、扫码、导入 cookie）单独标出来

你的工作方式
- 先弄清哪些会丢、哪些能留：电脑更新一般保留工作目录，但系统包、常驻进程、全局安装的命令行工具会丢；重置则什么都不留。所以要记的是“怎么重建”，不是去拷整台机器。
- 能从公开渠道重装的（apt、pip、npm、上游 Git 仓库）只记安装命令；自己写的代码必须进源码备份，否则重置后就找不回来。
- 收到登记先核对：路径是否真实存在、健康检查能不能过。登记写的和实际不一样时，以实际为准，并告诉负责的 Bot。
- 多个定时任务合并成一份 crontab 真源时，检查每一条是不是都在真源里，不在的要靠恢复脚本补回去。
- 故意停掉的服务要写清楚“为什么停、什么条件下重开”，免得被当成漏装。
- 只有主人说“电脑更新完了”才跑总恢复，不盲跑。跑完交验收：每项是成功、失败，还是要真人处理。
- 每次有服务新增、删除或源码大改，先重新同步源码备份，再把总账、脚本、源码一起提交推送到备份仓库。换账号或重置时，就靠这份备份把整套设定带走。
- 删掉的服务要彻底清除：总账只反映现在真实的状态。

프롬프트 2: 컴퓨터 초기화 후 Bot에게 전면 복구 실행 지시하기

Git 액세스 토큰을 설정한 후 괄호 내용을 수정하여 Bot에 전송합니다.

提示词二：电脑重置后让 Bot 执行全面恢复

这台电脑刚重置过（或者是换了新账号），之前部署的服务都没了。请按我的备份把它们恢复到可用状态，规则如下。

备份在哪
- 备份仓库：<你的备份仓库地址>，分支 <分支名>
- 仓库里有：登记总账（REGISTRY.md 和 registry.json）、每个服务的恢复脚本（restore/）、自写服务的源码备份（service-src/）
- 仓库里没有密钥，这是故意的

请按这个顺序做
1. 把备份仓库拉到工作目录，先读总账，告诉我一共登记了几项、哪些标了「必恢复」、哪些只留密钥不用恢复。先列出来，不要动手。
2. 把自写服务的源码从 service-src/ 放回总账写的原位置。只补缺失的，已经存在的目录不要覆盖。
3. 按总账的依赖顺序逐项恢复：先装系统依赖（比如 cron、ffmpeg），再装命令行工具，最后拉起常驻服务和定时任务。每项都用它自己的恢复脚本，脚本要能重复跑。
4. 每装完一项就跑它登记的健康检查。失败了先看日志、试着修一次；修不好就记下原因，接着做下一项，不要卡住。
5. 把需要我本人做的事汇总成一张清单：要重新提供的密钥（只说放哪个路径、叫什么名字，别让我把密钥贴进聊天）、要重新登录授权的工具（OAuth、扫码、设备码）。然后一项一项带我做，每做完一项马上复查。
6. 故意暂停的任务保持暂停，总账里写了原因和重开条件的照办。别因为“看起来漏装了”就自作主张打开。
7. 最后交验收清单，每项一行：服务名、结果（成功 / 失败 / 等我处理）、健康检查输出摘要、花了多久。再告诉我总共用了多少时间、成功了几项。

不要做的事
- 不要把任何密钥写进仓库、日志或聊天
- 不要跑总账没登记的安装
- 不要用“重置电脑”当修复手段
- 恢复完如果有任何改动（路径变了、版本升级了），更新总账，提交推回备份仓库

프롬프트 3: 기억 관리자 정기 아카이빙 지시어

Routine 또는 수동 아카이빙 시 다음을 전송합니다:

提示词三：记忆管家定期归档指令

请开始执行本周的智能体记忆与设定归档任务。

执行步骤：
1. 枚举当前工作区内所有处于活跃状态的 Bot 名单，核对 bots/ 目录下的已有目录。
2. 逐个通知名单内的 Bot：读取各自的 Description、人设规则与当前核心记忆，按三层结构（身份profile、历史决策与职责、当前现场快照）提炼并覆盖写入 /workspace/bots/<bot-slug>/MEMORY.md。同时将身份元数据更新至 agent-spec.md。
3. 检查各 Bot 回执，并在 /workspace 目录核对文件生成情况，确保所有目标 Bot 的 Markdown 均已写出。
4. 提取账号级共享记忆，更新至 shared-user-memory/ 目录下的 Markdown 文件中。
5. 对本次生成的所有 Markdown 文件进行敏感信息正则扫描，检查是否存在明文 API Token、密码或私钥。如果发现疑似凭证，立即中断并报警。
6. 扫描无异常后，执行 Git 操作：将所有更新文件暂存，提交信息标记为「memory snapshot YYYY-MM-DD」，推送到远端私有 Git 仓库，并打上对应日期的 Git Tag。
7. 完成后向我汇报：本次归档了哪几个 Bot、总文件大小、是否有失败或超时的 Bot。

21.7 자주 겪는 함정

1. Reconnecting이 표시될 때 Reset을 클릭하지 마세요. 단순한 네트워크 불안정이나 점검 상태일 뿐이며, 클릭하면 저장되지 않은 데이터를 이전 스냅샷으로 덮어쓰게 됩니다.
2. 여러 기기에서 Codex 인증을 공유하면 서로 연결이 끊기므로, 독립된 서브 계정이나 고정 자격 증명을 설정해야 합니다.
3. 머신 초기화 시 누락되는 것을 방지하기 위해 예약 작업은 crontab 설정 파일로 통합하여 Git에 포함해야 합니다.
4. 서비스 원장은 실제 실행 명령어를 기준으로 해야 하며, 환경에 Docker가 설치되어 있지 않으면 복구 스크립트가 멈출 수 있습니다.
5. Bot 내보내기는 완료 후 응답이 없는 경우가 많으므로, 관리자가 디스크를 직접 확인해야 하며 '작성 완료 후 반드시 보고'하도록 지시어에 강력히 제약을 걸어야 합니다.
6. 백업 저장소는 반드시 프라이빗으로 설정하고 정규식 스캔을 추가해야 합니다. Token이 Git push를 통해 공개 저장소로 유출되는 것을 방지해야 합니다.

21.8 완료 후 검수 방법

서비스 및 스크립트

1. 원장 대조: vm-services/REGISTRY.md를 대조하고, ps aux로 프로세스를 확인하며, netstat 또는 ss로 포트를 점검하여 경로가 과도하게 기록되거나 누락되지 않았는지 확인합니다.
2. 단독 테스트: restore-<服务名>.sh를 단독으로 실행하여 오류 없이 반복 실행이 가능한지 확인합니다.
3. 전체 리허설: 임시 디렉터리에 클론한 후 bash restore/restore-all.sh를 실행하여 '필수 복구' 항목이 모두 통과하는지 확인하고, 수동 개입이 필요한 단계가 목록으로 정리되었는지 확인합니다.

저장소 및 기억

1. 구조 확인: 웹 인터페이스에서 bots/를 확인하여 각 Bot마다 독립된 agent-spec.md와 MEMORY.md가 있는지 확인합니다.
2. 샘플링 점검: MEMORY.md를 열어 '신원 profile', '과거 의사결정 및 역할', '현재 현장 스냅샷'의 3개 계층이 완전하며 빈 템플릿이나 깨진 글자가 없는지 확인합니다.
3. 비밀 정보 검색: 전체 검색으로 sk-, Bearer 또는 password를 검색하여 자격 증명은 로컬 절대 경로만 남기고 평문 Token은 엄격히 금지되었는지 확인합니다.

더 읽어보기

• 공식 사용 가이드 및 지원 페이지:
  • 《Grok Bot 컴퓨터》
  • 《기밀 정보의 안전한 저장》
  • 《도움 받기》
  • 《Grok Bot 사용 가이드》
• 커뮤니티 실전 참고 기사:
  • 铁柱AGI @cgnot996: 《Grok Bot 가상 머신 초기화 후 도구가 모두 사라졌다면? 백업 및 복구 튜토리얼 (프롬프트 포함)》
  • 铁柱AGI @cgnot996: 《Grok Bot 百万撤离：一套完善的 Agent 系统备份方案》
  • 지식베이스 연계 정리: 《4.6 가상 머신, 기억 및 백업》