Restic y PostgreSQL: el backup que sí vuelve
Hacer backups no alcanza. Una pyme necesita restaurar rápido, probar copias y guardar versiones inmutables sin convertir el servidor en una caja negra.
El backup que sí vuelve empieza con una pregunta antipática: quién restauró ayer un archivo y lo abrió. En una bodega exportadora de Luján de Cuyo, el encargado de logística sostiene una etiqueta térmica arrugada mientras el sistema de despachos tarda en levantar. Restic documenta cifrado, deduplicación y verificación de repositorios; PostgreSQL 17 explica cómo archivar WAL para recuperación continua. La cifra escondida es menos técnica: una hora sin remitos puede dejar un camión cargado mirando la tranquera.
La próxima copia va a fallar en silencio
La encuesta 2024 de Stack Overflow ubicó a PostgreSQL con 48,7% de uso entre desarrolladores, una señal de adopción global que también entra en pymes argentinas por ERP, tableros y sistemas a medida. Pero usar una base robusta no garantiza poder volver atrás. PostgreSQL recomienda respaldos base combinados con archivado continuo de WAL para recuperar a un punto específico; si la pyme sólo copia el directorio de datos cada noche, puede estar guardando una foto rota.
La sospecha del área administrativa dice que "el servidor hace backup solo". Los datos obligan a preguntar dónde, con qué retención, bajo qué clave, contra qué borrado y cuándo se probó. MinIO documenta retención y bloqueo de objetos para evitar modificaciones o eliminación durante un período definido. Esa palabra, inmutable, suena grande hasta que alguien cifra el servidor con ransomware y descubre que la copia también estaba montada como carpeta escribible.
Un backup sin restauración es una estampita con cron.
La bodega no necesita una ceremonia; necesita un procedimiento que una persona pueda ejecutar con sueño y presión. La solución fácil suele comprar más almacenamiento. Ahí empieza el error.
Más disco compra tiempo, no regreso
La respuesta obvia es sumar un NAS, pagar más espacio en la nube o copiar todo a un disco USB que duerme en un cajón. Puede servir como parte del plan, pero no resuelve el síntoma si nadie separa datos vivos, copias versionadas y pruebas de recuperación. El antagonista es la carpeta "backup_final", un cementerio de ZIP con fechas ambiguas, permisos heredados y claves que sólo conoce el proveedor anterior.
La escena se toca con los dedos: polvo de corcho sobre el teclado, una Toyota Hilux esperando en la playa y un pendrive rojo atado a un llavero de metal. El encargado hace doble clic y ve tres archivos con el mismo nombre. Ninguno dice si contiene el remito correcto. El sistema no perdió información en un relámpago; la fue desordenando durante meses. La salida no empieza por comprar, sino por ensayar el regreso.
La salida abierta diseña el camino de vuelta
Una arquitectura práctica para pyme combina dumps lógicos de PostgreSQL para recuperación granular, backups físicos con WAL para volver a un punto de tiempo, Restic para repositorios cifrados y deduplicados, y almacenamiento S3 compatible con bloqueo de objetos en MinIO o un proveedor externo. La regla operativa es 3-2-1 con una vuelta más: tres copias, dos medios, una fuera del sitio y una prueba mensual documentada.
El costo puede empezar en USD 800 a USD 2.500 de implementación si ya existe orden básico en servidores, más USD 25 a 150 mensuales según volumen y retención. Al dólar de referencia de $1.416, eso equivale a unos ARS 1,1 a 3,5 millones de arranque y ARS 35.400 a 212.400 mensuales. En trabajos de infraestructura, UMSA suele separar el inventario de recuperación en tres columnas: qué se pierde, cuánto demora volver y quién firma que la prueba pasó.
El fenómeno merece nombre: copia bonsái. Parece un árbol, ocupa poco espacio y muere cuando alguien necesita sombra. Restic puede verificar integridad; PostgreSQL puede reconstruir una línea temporal; MinIO puede impedir borrados apresurados. Ninguna herramienta decide cuántas horas de facturación tolera la empresa. Esa decisión debe quedar escrita antes del incendio, no durante la llamada al técnico.
Antes de copiarlo, mirá la clave y el reloj
Primer riesgo: cifrar sin gobernanza de claves. Si la contraseña queda en el mismo servidor que se perdió, el plan se vuelve teatro. Segundo: retener demasiado poco. Un error humano detectado quince días tarde no se arregla con copias de siete días. Tercero: ignorar la hora. Sin NTP y registros consistentes, recuperar "hasta antes del error" se convierte en una discusión.
La prueba mínima tiene cuatro pasos: restaurar una base en otro servidor, abrir una aplicación contra esa copia, recuperar un archivo borrado y escribir cuánto tardó todo. Si la pyme no puede repetirlo cada mes, no tiene backup. Tiene esperanza comprimida.