La IA ha borrado la base de datos: un plan de recuperación en 7 minutos

En la documentación encontrarás información práctica sobre cómo trabajar con Ailoot.

¿Qué hacer primero si un agente de IA ha borrado una base de datos?#

Si te ocurre esto, lo primero que debes hacer es detener al agente. No intentes deshacer sus acciones por tu cuenta, no le digas que «lo restaure todo» y no le des nuevas instrucciones. Cada acción posterior del agente podría sobrescribir los bloques del disco donde quizá aún estén almacenados tus datos.

1. Cierra la terminal del agente

   Interrumpe inmediatamente el comando peligroso con Ctrl+C; no esperes a que termine de borrar. Detener el agente no detiene necesariamente sus comandos hijos, trabajos remotos o consultas. Identifica el proceso escritor real y detén o cancela la operación; escala la terminación si continúa destruyendo datos. Mantén vivos los procesos ajenos con archivos abiertos recuperables.

2. NO reinicies el portátil

   Los datos borrados pueden seguir siendo recuperables, pero depende del almacenamiento, base de datos, descarte/TRIM y escrituras posteriores. Minimiza escrituras en el volumen afectado; no supongas que los bytes siguen existiendo.

3. NO cierres los procesos abiertos

   Conserva procesos ajenos que mantengan abiertos archivos eliminados: puede ser posible recuperar mediante sus descriptores. No se aplica al proceso destructivo: detenlo primero. No dejes un borrado en marcha solo por conservar un descriptor.

4. Empieza a grabar la pantalla

   Registra hora exacta, rutas afectadas y salida visible de comandos. Guarda grabaciones o registros en otro dispositivo verificado, no en el volumen dañado. Conserva allí archivos supervivientes seguidos, sin seguimiento e ignorados y metadatos Git antes de recuperar.

A continuación, tienes 6 minutos para recuperarte. Vamos allá.

Minutos 2–3: documenta exactamente qué salió mal#

Abre una ventana de terminal nueva. No la que está usando el agente: otra. Ejecuta estos tres comandos en orden.

1. Registra exactamente qué ha cambiado en el repositorio de Git:

git status
git log --since="30 minutes ago" --all --oneline

Un archivo seguido eliminado puede existir todavía en el índice o un commit. Conserva el árbol actual, incluidos archivos sin seguimiento e ignorados, antes de restaurar; hacerlo sobre la copia original puede sobrescribir ediciones supervivientes. Inspecciona y recupera en otra copia.

2. Comprueba qué procesos del agente están en ejecución:

ps aux | grep -i claude
ps aux | grep -i cursor

Identifica qué proceso sigue haciendo escrituras peligrosas; coincidir en nombre no basta. Detén ese proceso y verifica que se haya parado. Conserva los ajenos con archivos abiertos útiles; si no termina de forma ordenada y sigue destruyendo, puede ser necesaria una terminación forzada.

3. Guarda el registro de sesión del agente:

Claude Code guarda las sesiones JSONL en ~/.claude/projects/. Cursor las guarda en ~/.cursor/. Haz una copia ahora mismo:

cp -r ~/.claude/projects /external/incident-evidence/claude-projects

Sustituye /external/incident-evidence/ por un directorio de pruebas existente en otro dispositivo montado y verificado. No copies sobre el volumen afectado ni sobrescribas pruebas existentes. Esta carpeta contiene la conversación íntegra con el agente: qué comandos ejecutó, qué respondió y en qué orden. Es tu principal fuente para investigar el incidente y, posiblemente, recuperar archivos eliminados a partir de su contexto (consulta el paso 4).

Minuto 4: git reflog, tu mejor oportunidad#

git reflog registra movimientos locales de referencias mientras se conserven sus entradas. Caducidad y poda varían y pueden eliminar objetos inalcanzables: no es un archivo garantizado de todos los commits pasados. Ejecuta los pasos siguientes desde una copia preservada en el dispositivo separado.

Paso 1. Consulta el registro:

git reflog --all

Verás una lista parecida a esta:

1a2b3c4 HEAD@{0}: reset: moving to HEAD~3
9z8y7x6 HEAD@{1}: commit: working version of the dashboard
5w4v3u2 HEAD@{2}: commit: added admin panel

Busca el punto anterior a los daños causados por el agente. Cada entrada es una «instantánea» del estado del repositorio en ese momento.

Paso 2. Recupera en otro árbol de trabajo:

Después de copiar repositorio y trabajo superviviente a otro dispositivo, ejecuta desde esa copia preservada. Sustituye el valor por el SHA exacto comprobado en reflog y elige rama y destino sin usar:

RECOVERY_COMMIT='replace-with-verified-commit-sha'
git worktree add -b recovery-check ../recovery-check "$RECOVERY_COMMIT"

Inspecciona ../recovery-check y compara con los archivos sin commit preservados antes de copiar nada de vuelta. El comando extrae el commit por separado, sin reiniciar el árbol dañado. Los worktrees vinculados comparten los objetos Git de la copia: es un espacio de recuperación, no un respaldo independiente. Consulta la documentación oficial de git-worktree.

Si también se ha limpiado reflog (el agente ha conseguido ejecutar git gc):

git fsck --lost-found

Este comando encuentra commits y blobs (objetos de archivo) «perdidos» que ya no están vinculados a ninguna rama. Aparecerán en .git/lost-found/commit/ y .git/lost-found/other/. Para restaurar un archivo desde allí:

git cat-file -p <SHA1-blob> > recovered-file.ext

Cuándo NO ayuda git reflog:

• El archivo solo estaba en el árbol de trabajo, sin commit ni stash → reflog no puede encontrarlo
• Han pasado más de 90 días (el valor estándar de gc.reflogExpire) y se ha ejecutado git gc
• Se ha eliminado todo el repositorio (rm -rf .git): en ese caso necesitas Time Machine o una instantánea

Minuto 5: restaura la base de datos desde una copia de seguridad#

La base de datos se eliminó con DROP DATABASE, DROP TABLE o DELETE FROM ... WHERE ... (sin cláusula WHERE). ¿Qué debes hacer?

Paso 1. Averigua si tu proveedor ofrece PITR:

Paso 2. Restaura en una instancia nueva, no en la anterior:

No restaures nunca sobre una base de datos activa. Crea una instancia nueva a partir de la copia de seguridad y luego cambia la aplicación para que la utilice. Si algo sale mal, puedes volver a cambiar el DNS.

Paso 3. Si PITR no estaba habilitado, utiliza la instantánea más reciente:

# AWS RDS, list snapshots:
aws rds describe-db-snapshots --db-instance-identifier my-db

# Restore from a snapshot:
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier my-db-restored \
  --db-snapshot-identifier rds:my-db-2026-05-28-12-00

Particularidad de Supabase que sorprendió a mucha gente en 2026: cuando se habilita PITR, dejan de crearse copias de seguridad diarias. Es un comportamiento contrario a la intuición; podrías acabar sin ninguna copia de seguridad. Comprueba en Dashboard → Database → Backups que PITR esté activo Y que tengas una instantánea desde la que restaurar.

Minuto 6: Time Machine, lsof e instantáneas del disco#

macOS: Time Machine:

# List snapshots:
tmutil listbackups

# Restore a file from the latest backup:
tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx

Time Machine crea instantáneas cada hora, conserva las horarias durante un día y las diarias durante una semana, y mantiene las semanales indefinidamente. Si tu portátil está conectado a una Time Capsule o a una unidad externa, tu proyecto estará allí con granularidad horaria.

Linux: el archivo se ha eliminado, pero un proceso aún lo tiene abierto:

# Find all “deleted” files that a process still has open:
sudo lsof | grep deleted

# You'll get lines like:
# node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted)

# Copy the file directly from /proc/PID/fd/N:
sudo cp /proc/12345/fd/24 ~/recovered-file.txt

Las posibilidades de éxito son de aproximadamente el 95 % si no se ha cerrado el proceso. Funciona con ext4, xfs y btrfs.

macOS: equivalente mediante lsof:

lsof | grep deleted

Copiar el archivo es más complicado (no hay /proc/), pero puedes hacerlo con lldb:

lldb -p 12345
(lldb) memory read --outfile recovered.txt --binary 0xADDRESS 0xSIZE

Instantánea de todo el disco (Linux, último recurso):

sudo dd if=/dev/sda1 of=/external/disk-image.img bs=4M status=progress

Esto guarda toda la partición como una imagen. Después, recupera los datos con extundelete o photorec. Las posibilidades de recuperación dependen de cuántos datos se hayan escrito en el disco desde la eliminación. Si no se ha escrito nada, son del 80–90 %. Si el disco lleva una hora en uso, son del 20–30 %.

Minuto 7: qué hacer si no hay ninguna copia de seguridad#

Opción 1: soporte del proveedor:

AWS, Yandex Cloud, Google Cloud y DigitalOcean recuperan periódicamente datos de su almacenamiento interno, incluso después de un desastre en las instalaciones de un cliente, especialmente en los planes de pago. Abre un ticket de soporte, indica la hora exacta del incidente e incluye capturas del estado. Suele funcionar mejor con proveedores importantes que mantienen copias de seguridad automáticas por su cuenta. Las posibilidades son del 40–60 %; el plazo de respuesta es de 24–72 horas.

Opción 2: versionado de S3:

Si los archivos estaban en S3 (o Yandex Object Storage) y el versionado estaba habilitado, todas las versiones existen físicamente; simplemente están marcadas como «eliminadas».

# AWS—list versions:
aws s3api list-object-versions --bucket my-bucket --prefix files/

# Restore a version:
aws s3api copy-object \
  --bucket my-bucket \
  --copy-source my-bucket/files/data.json?versionId=ABC123 \
  --key files/data.json

Aviso importante: Claude Code no conserva las sesiones para siempre; los archivos JSONL antiguos se eliminan automáticamente después de varias semanas. Para asegurarte de tener un mes de historial JSONL en caso de desastre, copia ~/.claude/projects/ a una unidad externa una vez por semana mediante una sencilla tarea cron:

# In crontab, every Sunday at 03:00:
0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/

Es gratis y te salva cuando «todo ha desaparecido, no hay copia de seguridad y reflog está vacío».

7 reglas para evitar que vuelva a ocurrir#

1. Plan Mode antes de cualquier operación destructiva. En Claude Code:

claude --plan

El agente prepara un plan antes de actuar. Lo lees, ves DROP TABLE users y cancelas. Sin Plan Mode, el agente decide por su cuenta y ejecuta la acción en milisegundos. Obtén más información en la guía de Plan Mode en Claude Code.

2. Hooks como alarma adicional. Usa un PreToolUse probado que lea JSON desde stdin y devuelva 2 al detectar alto riesgo. El ejemplo completo siguiente cubre Bash, Write y Edit; no es un límite de seguridad y puede omitir operaciones indirectas. Conserva permisos de base de datos y sandbox restringidos.

3. Un usuario de base de datos de solo lectura para el agente. Crea un usuario independiente para el agente que no tenga permisos DROP, TRUNCATE ni DELETE:

CREATE USER claude_readonly WITH PASSWORD 'xxx';
GRANT CONNECT ON DATABASE myapp TO claude_readonly;
GRANT USAGE ON SCHEMA public TO claude_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO claude_readonly;

Cuando el agente necesite escribir de verdad, cambia manualmente a otro usuario. Un usuario de solo lectura basta para las tareas cotidianas (análisis de datos, informes y paneles).

4. Guarda en Git los cambios revisados. Un hook PostToolUse en .claude/settings.json puede mostrar un recordatorio después de Write y Edit:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'Revisa el diff y crea manualmente un commit solo con los archivos acordados.' >&2"
          }
        ]
      }
    ]
  }
}

Este ejemplo solo muestra un recordatorio; no añade archivos al área de preparación ni crea commits. Revisa el diff y crea manualmente un commit solo con los archivos acordados. El reflog no guarda cambios que no se hayan incluido en un commit.

5. Proyecto sandbox para experimentos. No dejes nunca que el agente trabaje en un proyecto que contenga datos reales de clientes. Crea una carpeta independiente ~/sandbox-projects/, con una copia del proyecto y datos sintéticos. Úsala para probar un prompt, un agente o un servidor MCP nuevos. Si algo se rompe, no habrá daños.

6. Instantáneas del disco con restic cada hora.

# Install:
brew install restic  # macOS
sudo apt install restic  # Linux

# Create repository:
restic init --repo /external/backups

# Back up the current project:
restic --repo /external/backups backup ~/projects

# Schedule cron every hour:
crontab -e
# Add:
0 * * * * restic --repo /external/backups backup ~/projects

Siete días de copias de seguridad cada hora, cuatro semanas de copias diarias y la posibilidad de volver a cualquier punto anterior. Es gratis y se configura en 10 minutos.

7. Archiva las sesiones JSONL de Claude Code. Ya lo hemos mencionado, pero lo repetimos como regla independiente: programa una copia semanal con rsync de ~/.claude/projects/ a una unidad externa. Es gratis y solo requiere una línea en crontab.

Hooks listos para bloquear comandos peligrosos#

Combina esta entrada con .claude/settings.json sin reemplazar los hooks existentes:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/check-risk.py\""
          }
        ]
      }
    ]
  }
}

Crea .claude/hooks/check-risk.py con este script Python 3:

import json
import re
import sys
from pathlib import Path

try:
    event = json.load(sys.stdin)
    tool = event["tool_name"]
    data = event["tool_input"]
    blocked = False
    if tool == "Bash":
        command = data["command"]
        blocked = bool(re.search(
            r"drop\s+(database|table)|truncate\s+table|"
            r"delete\s+from.*where\s+1|rm\s+-rf|"
            r"git\s+reset\s+--hard|git\s+push.*(--force|-f)|"
            r"chmod\s+-R\s+777",
            command, re.IGNORECASE | re.DOTALL))
    elif tool in ("Write", "Edit"):
        path = Path(data["file_path"]).resolve()
        blocked = (".git" in path.parts or path.name.startswith(
            (".env", "credentials", "secrets")))
except (ValueError, KeyError, TypeError, OSError):
    print("BLOCKED: invalid hook input", file=sys.stderr)
    sys.exit(2)

if blocked:
    print("BLOCKED: high-risk command or sensitive path", file=sys.stderr)
    sys.exit(2)
sys.exit(0)

Lee el evento JSON documentado de stdin, comprueba tool_input.command o tool_input.file_path y devuelve 2 si coincide. Cubre Write y Edit. Prueba un caso inocuo permitido y otro bloqueado y comprueba que Python y el script configurado se inicien realmente.

Es una alarma léxica: puede omitir argumentos reordenados, scripts, alias, comandos ofuscados, otras herramientas y escrituras indirectas, o rechazar ejemplos inocuos entrecomillados. No concede ni elimina permisos del sistema o base de datos. Mantén credenciales productivas fuera del entorno, usa rol de base de datos de solo lectura y sandbox obligatorio y protege la configuración del hook. Consulta la referencia oficial de entrada y códigos de salida.

Para una operación excepcional intencionada, revísala y ejecútala fuera del agente con la cuenta restringida adecuada. Una variable de entorno del shell no es una interfaz documentada para desactivar hooks; estos no gobiernan comandos de terminal normales.

Cuándo dar permisos a la IA (y cuándo no)#

Anthropic documenta el indicador --dangerously-skip-permissions (también conocido como modo YOLO) como una opción para «entornos de confianza». En la realidad de 2026, es un camino directo al desastre. Cuando un agente no tiene que pedir permiso:

• ejecuta cualquier comando Bash sin confirmación
• escribe archivos sin preguntar
• puede invocar un subagente, que hereda YOLO sin posibilidad de deshacerlo

El tercer punto es el más insidioso. Si inicias el agente principal con YOLO, sus subagentes también están en modo YOLO y no puedes anularlo. Basta un prompt para que una cascada de 10 agentes en paralelo pueda hacer cualquier cosa en tu sistema.

Regla:

Alternativa: permisos precisos. En .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(git status:*)",
      "Bash(git log:*)",
      "Bash(npm run build:*)",
      "Read(*)",
      "Edit(src/**)"
    ],
    "deny": [
      "Bash(rm:*)",
      "Bash(git push:*)",
      "Edit(.env)",
      "Edit(prisma/migrations/*)"
    ]
  }
}

El agente ve qué está permitido y qué no. No tienes que hacer clic en «sí» o «no» cada vez: el agente trabaja rápido y tú controlas el perímetro.

Siguiente paso: una lista de comprobación de 7 minutos para guardar#

Lista de comprobación: «La IA lo ha borrado, ¿qué hago?»

1. Detén inmediatamente el proceso destructivo real y verifica que hayan parado sus operaciones hijas o remotas
2. No reinicies; conserva los procesos ajenos con archivos eliminados abiertos
3. Registra hora del incidente y pruebas de comandos en otro dispositivo verificado
4. Copia archivos supervivientes, metadatos Git y registros pertinentes en ese dispositivo separado
5. En la copia preservada, inspecciona git reflog --all y recupera un commit verificado en otro worktree
6. Si Git no ha ayudado: git fsck --lost-found
7. Base de datos: PITR (AWS/Yandex/Supabase) o la instantánea más reciente
8. Archivos: Time Machine en Mac, lsof en Linux
9. Último recurso: soporte del proveedor + versionado de S3
10. Después de la recuperación, configura las 7 reglas preventivas de esta guía

Siguiente paso: protección sistemática:

• Plan Mode en Claude Code: para que el agente planifique antes de realizar una operación destructiva
• Hooks en Claude Code: plantillas listas para bloquear comandos peligrosos
• Cómo revertir cambios en Claude Code: guía detallada sobre /rewind, Git y 5 métodos estándar de reversión
• Revisión de seguridad en Claude Code: comprobaciones periódicas de la seguridad del código

Abrir Ailoot.