Operación de data-base-dumper

Cuándo usar este documento

Para verificar que los respaldos se están generando, o para ejecutar uno fuera de calendario.

Audiencia

Infraestructura y soporte.

Estado documental

• Estado: Borrador
• Última actualización: 2026-08-02
• Owner: Pendiente
• SME requerido: DevOps
• Fuente resumida: entradas de cron declaradas en la configuración de despliegue del repositorio.

Tareas recurrentes

Semanales

Los volcados están escalonados los sábados por la mañana para no competir entre sí:

Hora	Proveedor	Log
05:00	Base del MEM	Log del proveedor
05:05	Instancia de participante	Log del proveedor
05:15	Instancia de participante	Log del proveedor

Diarias

Hora	Tarea	Comando
05:20	Limpieza de volcados locales	clear:sql-dumps

La limpieza corre a diario aunque los volcados sean semanales, para que un archivo grande no quede ocupando disco.

Duplicidad de respaldos sin resolver

El repositorio server-configs define otro mecanismo de respaldo, con un script propio que corre los domingos y cubre las mismas bases.

Es decir: hay dos rutinas de respaldo, en días distintos, con implementaciones distintas.

No está confirmado si ambas están activas, si una reemplazó a la otra sin retirarla, o si son complementarias. Antes de confiar en cualquiera de las dos como respaldo de referencia, hay que verificar cuál está realmente corriendo en el servidor.

Verificaciones

¿Se generó el respaldo de la semana?

1. Revisar en Slack la notificación de cada proveedor.
2. Confirmar en S3 que existe el archivo de la semana para cada base.
3. Revisar el log del proveedor si algo falta.

¿Hay volcados locales acumulados?

Revisar el directorio de volcados del servidor. Si crecen, la rutina de limpieza no está corriendo.

Ejecución manual

php app dumper:dump-database --provider=<servicio>
php app clear:sql-dumps

Un volcado consume recursos

Generar el volcado de una base grande impacta al servidor y a la base de origen. Ejecutarlo fuera de las ventanas operativas críticas: nunca entre 05:00 y 08:30 en días hábiles, ni durante el ciclo mensual de facturación.

Cuándo ejecutar uno fuera de calendario

• Antes de una migración de base de datos de gran alcance.
• Antes de un despliegue con cambios de esquema significativos.
• Antes de ejecutar un comando destructivo, como la eliminación de precios sincronizados.
• Antes de una corrección masiva de datos.

Si falla

Síntoma	Causa probable	Acción
No llegó la notificación a Slack	El cron no corrió, o el token de Slack es inválido.	Verificar cron y revisar el log del proveedor.
Notificación de error	Credenciales de base o de AWS, o espacio en disco.	Leer el mensaje de error del log.
El volcado se generó pero no está en S3	Credenciales de AWS o permisos del bucket.	Revisar el log; el archivo local pudo eliminarse igual.
Disco lleno	La limpieza no está corriendo.	Ejecutar clear:sql-dumps y revisar su cron.

Riesgos y gaps

• Sin procedimiento de restauración documentado. Un respaldo que nadie sabe restaurar no es un respaldo.
• Sin verificación de integridad: se notifica que el volcado se generó, no que sea restaurable.
• Duplicidad de mecanismos sin resolver.
• Política de retención no documentada.
• No está documentado quién recibe y revisa las notificaciones de Slack.

Próxima revisión

Al documentar el procedimiento de restauración.