Backups que de verdad se restauran

Los modos de fallo que nadie prueba

Los fallos de backup rara vez son dramáticos. El cron job se ejecutó, el archivo llegó, el panel siguió en verde — y el dump está silenciosamente corrupto, o los segmentos WAL y los binlogs necesarios para la recuperación a un punto en el tiempo nunca se enviaron. Nada se queja hasta que intentas cargarlo.

Los fallos humanos son igual de comunes: las credenciales del bucket de backups caducaron hace meses, o la restauración técnicamente funciona pero tarda un día entero porque nadie la midió nunca contra un conjunto de datos del tamaño de producción. Todos estos casos pasan la checklist de '¿tenemos backups?'. Ninguno pasa una restauración.

Qué respaldamos, y con qué frecuencia

Cada base de datos gestionada en Anested Cloud — PostgreSQL, MongoDB y MySQL — recibe un snapshot diario, automáticamente, sin configuración alguna. Las ventanas de retención crecen con tu plan, para que puedas llegar más atrás en el historial a medida que crecen tus necesidades, y la programación nunca depende de que alguien recuerde un cron job.

Igual de importante es dónde viven esos backups: en un dominio de fallo separado de la propia base de datos, sobre infraestructura de almacenamiento independiente. Un incidente que tumbe el host de tu base de datos no puede tumbar sus backups al mismo tiempo — esa separación es precisamente el objetivo.

Restaurar es una función del producto, no un runbook

En demasiadas pilas, 'restaurar' significa una página de wiki escrita hace dos años, tres sesiones de ssh y una oración. Nosotros tratamos la restauración como una función de producto de primera clase: desde el panel, elige un snapshot y restáuralo a una base de datos nueva con un clic, mientras la original sigue funcionando sin tocarse.

Ese diseño elimina la parte más aterradora de un mal día — el miedo a empeorar las cosas. Inspeccionas la copia restaurada, la verificas con el informe que generamos y solo cambias tu cadena de conexión cuando estás satisfecho.

• Restaurar a una instancia nueva — nunca sobrescribir en el sitio
• Verificar con un informe de checksum y conteo de filas
• Conservar la original durante 7 días

Haz tu parte: prueba una restauración

Nosotros nos encargamos de la maquinaria, pero solo tú sabes qué aspecto tiene lo 'correcto' para tus datos. El mejor hábito es un simulacro trimestral de restauración: lleva un backup reciente a una base de datos de staging y comprueba que los números tienen sentido. Toma unos 10 minutos y convierte tus backups de esperanza en evidencia.

Para una base de datos PostgreSQL, todo el simulacro cabe en tres líneas. Ponlo en un script, añade un recordatorio en tu calendario y ejecútalo una vez al trimestre:

# restore drill
pg_dump "$PROD_URL" | psql "$STAGING_URL"
psql "$STAGING_URL" -c "select count(*) from users;"

Backups también para los archivos

Las bases de datos no son lo único que merece protección. Las subidas de usuarios y los recursos estáticos en Nest Storage pueden protegerse con versionado de objetos, de modo que una sobrescritura o un borrado accidental deja la versión anterior recuperable en lugar de perdida.

Y para todo lo que vive en un VPS — configuraciones, código de la aplicación, ese directorio que nadie recuerda haber creado — las opciones de snapshot permiten capturar el estado completo de la máquina y volver a él. El principio es el mismo en todas partes: una copia que de verdad puedes restaurar, guardada aparte de aquello que protege.