Mi Estrategia de Respaldo OpenClaw Sin Rodeos

Una vez perdí una semana configurando OpenClaw. No por un hackeo o un fallo de hardware. Porque ejecuté una actualización del sistema que corruptió mi tarjeta SD. Todo — mi configuración, mis habilidades personalizadas, mis archivos de memoria, mis definiciones de cron job — desapareció.

Reconstruirlo tomó todo un fin de semana. Y la parte peor: sabía que debía tener copias de seguridad. Simplemente seguía posponiéndolo porque “lo configuraré mañana”.

Esta es la estrategia de copia de seguridad que uso ahora. Toma 20 minutos configurarla y funciona automáticamente. Sin excusas.

Qué Necesita Copia de Seguridad

No todo. OpenClaw en sí puede reinstalarse. El sistema operativo puede volver a flashearse. Lo que no se puede recrear fácilmente:

Archivos de configuración. Tu configuración principal (YAML), claves de API, configuraciones de modelo, configuraciones de integración. Esto son horas de ajustes cuidadosos que no querrás rehacer.

Archivos de memoria y espacio de trabajo. Memoria a largo plazo, notas diarias, documentación de proyectos, instrucciones personalizadas. Este es el conocimiento acumulado de tu agente.

Habilidades personalizadas. Cualquier habilidad que hayas escrito o modificado. Las habilidades de la comunidad pueden reinstalarse, pero las tuyas personalizadas existen solo en tu máquina.

Historial de sesiones. Opcional: depende de si te importan las conversaciones pasadas. Mantengo 30 días de historial para referencia, pero no lloraría si desapareciera.

Definiciones de cron job. Tus tareas programadas y sus configuraciones. Recrear estas de memoria es propenso a errores.

La Estrategia de Copia de Seguridad

Tres capas, cada una con un propósito diferente:

Capa 1: Copia de seguridad local diaria. Un cron job que se ejecuta a las 2 AM, copia los directorios críticos a una carpeta fechada en la misma máquina. Esto protege contra eliminación accidental y errores de configuración. Si cometo un error en un archivo de configuración a las 3 PM, puedo restaurar la versión de anoche en segundos.

Retención: 7 días de copias de seguridad diarias. Las más antiguas se eliminan automáticamente.

Capa 2: Copia de seguridad remota diaria. Después de que la copia local se completa, rsync copia la copia de seguridad a una segunda máquina (uso un NAS en mi red doméstica, pero un VPS económico también funciona). Esto protege contra fallos de hardware. Si la tarjeta SD del Pi se muere, la copia de seguridad existe en otro lugar.

El comando rsync es simple: rsync -az --delete /backup/openclaw/ nas:/backups/openclaw/. La opción --delete mantiene la copia remota sincronizada sin crecer indefinidamente.

Capa 3: Copia de seguridad semanal en la nube. Cada domingo, los archivos de configuración críticos (solo las cosas pequeñas — configuración, habilidades, archivos de memoria — alrededor de 5 MB en total) se encriptan y suben a almacenamiento en la nube. Esta es la capa de recuperación ante desastres. Si mi casa se quema y se lleva tanto el Pi como el NAS, aún tengo mis configuraciones.

Uso rclone para sincronizar con Backblaze B2 (centavos por mes por esta cantidad de datos). Los archivos se encriptan localmente antes de la subida usando GPG.

El Script de Copia de Seguridad

La copia de seguridad completa es un script bash de unas 30 líneas:

1. Definir los directorios a respaldar (configuración, espacio de trabajo, habilidades, sesiones)
2. Crear un tarball fechado de esos directorios
3. Mantener los últimos 7 tarballs locales, eliminar los más antiguos
4. Rsync el tarball más reciente al servidor remoto
5. Los domingos: encriptar y subir al almacenamiento en la nube
6. Registrar el resultado (éxito/fallo, tamaños, duración)

El script se ejecuta a través de cron a las 2 AM diariamente. Tiempo total de ejecución: alrededor de 30 segundos para una instalación típica.

Pruebas de Restauración

Una copia de seguridad que nunca has probado no es una copia de seguridad — es una esperanza.

Cada mes, realizo una prueba de restauración. No en mi Pi de producción — en una tarjeta SD de repuesto. Flasheo un nuevo sistema operativo, instalo OpenClaw, resto de la copia de seguridad y verifico que todo funcione. La prueba completa toma alrededor de 30 minutos.

Cosas que he captado en pruebas de restauración:
– Una ruta de copia de seguridad que cambió después de una actualización de OpenClaw (la estructura de directorios se movió)
– Una definición de cron job que hacía referencia a una ruta local no incluida en la copia de seguridad
– Una clave de API que se almacenó en una variable de entorno en lugar de en el archivo de configuración (y por lo tanto no fue respaldada)

Cada una de estas habría sido una sorpresa desagradable durante una recuperación real. Es mejor encontrarlas durante una prueba tranquila del sábado que durante una emergencia a las 3 AM.

El Procedimiento de Recuperación

Cuando las cosas salen mal, quieres una lista de verificación, no un árbol de decisiones. Aquí está la mía:

1. Flashear un nuevo sistema operativo en una nueva tarjeta SD / SSD
2. Instalar Node.js y OpenClaw
3. Copiar el tarball de la copia de seguridad al nuevo sistema
4. Extraer a los directorios correctos
5. Verificar claves de API y conexiones
6. Iniciar OpenClaw y verificar funcionalidad básica
7. Comprobar cron jobs y tareas programadas
8. Verificar que los archivos de memoria y espacio de trabajo estén intactos

Tiempo total de recuperación: alrededor de 45 minutos desde una tarjeta SD en blanco hasta un sistema completamente operativo. Compara eso con el fin de semana que pasé reconstruyendo sin copias de seguridad.

Lo que la Mayoría de las Personas Hace Mal

Copia de seguridad excesiva. No necesitas respaldar todo el sistema. El sistema operativo y OpenClaw en sí se reinstalan fácilmente. Respaldar solo lo que es único en tu instalación.

No respaldar claves de API. Si tus claves de API están en variables de entorno en lugar de archivos de configuración, no estarán en tu copia de seguridad. Muévelas al archivo de configuración o mantén un documento seguro separado con todas las claves.

Sin copia remota. Una copia de seguridad en la misma máquina que falla no es ninguna copia de seguridad. Como mínimo, copia a una segunda máquina. La versión más simple: envíate por correo el archivo de configuración una vez a la semana.

Nunca probar restauraciones. Prueba tu proceso de restauración antes de necesitarlo. El momento de descubrir que tu copia de seguridad es incompleta no es durante una emergencia.

🕒 Published: March 25, 2026