Disaster Recovery Runbook¶
Estado¶
- Fecha de certificacion:
2026-05-31 - Alcance: auditoria real, backup restaurable y simulacion controlada sin tocar produccion
- Host auditado:
srv977009 - Estado operativo actual: OpenClaw
UP (healthy), NPMUP, PortainerUP - Certificacion DR actual:
VERDE - Backup recurrente actual:
VERDE - Documento detallado:
docs/BACKUP-RESTORE-STRATEGY.md
Safe Point Inicial¶
- Workspace local:
git status -sb-> limpiogit rev-parse HEAD->6445ca4e989d3ac287ce658ec4badf96ac006476- Host remoto:
hostname->srv977009docker ps->openclaw-openclaw-gateway-1,nginx-proxy-manager,portainer
Evidencia resumida¶
- OpenClaw auditado en
/opt/stacks/openclawcon: docker-compose.yml.envconfig/workspace/auth-profile-secrets/- NPM auditado en
/docker/nginx-proxy-managercon: docker-compose.ymldata/letsencrypt/- Portainer auditado en el volumen activo:
portainer_data_new- mountpoint real:
/var/lib/docker/volumes/portainer_data_new/_data - Simulacion controlada ejecutada en:
/tmp/dr-green-20260531-011407- Backups reales generados:
openclaw-stack.tgznpm-stack.tgzportainer-volume.tgz- Restore no destructivo validado por extraccion en staging.
Evidencia de auth OpenAI¶
auth-profile-secrets/existe pero esta vacio.- La persistencia real observada queda en el bind mount
config/: config/agents/main/agent/auth-profiles.jsonconfig/agents/main/agent/auth-state.jsonconfig/identity/device-auth.json- Mecanismo:
./config:/home/node/.openclawpersiste esos archivos fuera del contenedor, por lo que sobreviven adocker compose up -d.
RTO y RPO certificados¶
- Volumen total auditado para DR dedicado:
- OpenClaw:
715937 Bconfig +37562 Bworkspace +969 B.env - NPM:
1149405 Bdata +46827 Bletsencrypt +510 Bcompose - Portainer:
527043 Bvolumen activo - Backups comprimidos observados:
- OpenClaw:
f2a659b9a4564b2561779d39842b46c83a439e76f389a9c1580313a3d7e9d20f - NPM:
cf64d4a8bef17a6f8c4c3ea8637e951c0b69abab91cd9461e35f16de10852c43 - Portainer:
fd8c9385307ee27c5525c8089baee94aa1eae68e4d8968ac5a212cf8e75c2a32 - RTO conservador certificado:
- fallo de contenedor en mismo VPS:
15 minutos - reconstruccion del stack en mismo VPS con backups validados:
30-45 minutos - reprovision completo de VPS + restore documentado:
90-180 minutos - RPO certificado:
0para el set respaldado en la simulacion del2026-05-31- operativo recurrente esperado:
24 horas
Operacion recurrente¶
- Backup diario VPS:
- cron
03:00 - script:
/root/openclaw-backups/bin/openclaw-vps-backup.sh - Retencion:
- diarios
30 dias - semanales
12si la corrida ocurre en domingo - logs
90 dias - Rutas:
/root/openclaw-backups/daily/<timestamp>/root/openclaw-backups/weekly/<YYYY-weekWW>/root/openclaw-backups/logs/- Verificacion:
crontab -lls -l /root/openclaw-backups/daily/<timestamp>cat /root/openclaw-backups/daily/<timestamp>/SHA256SUMScat /root/openclaw-backups/daily/<timestamp>/manifest.txt
Evidencia fuera del VPS¶
- Script Windows:
scripts/backup/pull-openclaw-backups-to-windows.ps1- Destino local aprobado:
C:\APV\backups\openclaw\- Estado:
- copia manual probada
- automatizacion pendiente de aprobacion separada
Certificacion final¶
- Estado final:
VERDE
Motivos¶
- Existe inventario completo con rutas reales, tamanos y metodo de restore.
- Existe backup restaurable de OpenClaw, NPM y Portainer.
- Existe simulacion controlada no destructiva con extraccion valida.
- La persistencia real de auth OpenAI quedo trazada a archivos concretos.
- El restore teorico deja de depender solo del snapshot del proveedor.
Riesgos residuales¶
- El backup del host completo sigue dependiendo de snapshot o reprovision manual; no se verifico el panel Hostinger en esta sesion.
portainer.dbse respalda como archivo binario del volumen porque no expone una base SQLite legible desde el host.- La calidad del RPO futuro depende de ejecutar el backup antes de cambios y con periodicidad definida.
Proximo paso unico recomendado¶
Automatizar la descarga externa en Windows con Task Scheduler sin mover los
backups al repo y sin relajar permisos ni exposicion de secretos.