Matías Canteros

Migración Oracle RMAN Plugin → Veeam Guest Processing

Más de 100 bases de datos Oracle respaldadas dos veces. No era un error. Era el proceso.
El plugin de RMAN hacía el backup de cada base; el job de VM guardaba el servidor completo. Dos flujos, dos almacenamientos, misma información. En un entorno con Oracle 18c y 19c, standalone y en RAC, sobre Linux con ASM, ese costo se multiplica rápido y en silencio.

Lo que construimos para llegar a producción

• →Reuniones de alineamiento con los equipos DBA para mapear cada tipo de instancia y sus particularidades
• →Definición de equipos y responsabilidades para las pruebas POC
• →Diseño del set de pruebas de restore por escenario: standalone, RAC, ASM, filesystem
• →Ejecución de pruebas piloto con documentación formal de resultados
• →Plan de migración por fases con criterios explícitos para avanzar o frenar
• →Documentos de confirmación de cada POC firmados antes de tocar producción

Lo que se alcanzó con la migración

La parte técnica fue la más corta del proyecto. Lo que realmente lo hizo posible fue la coordinación entre equipos y tener cada decisión respaldada por documentación antes de avanzar.

Migración de Backup: HP Data Protector → Veeam & Ansible

Una plataforma de backup legacy con incompatibilidades técnicas crecientes, servidores HP-UX sin soporte en las herramientas modernas y 65 activos que necesitaban protección garantizada. El desafío no era solo migrar: era no dejar ningún sistema sin cobertura, incluyendo los que ninguna herramienta estándar podía proteger.

Resultados por categoría

Mejoras y beneficios obtenidos

El proyecto cerró con el 100% de los activos cubiertos. La solución Ansible para HP-UX fue la pieza clave: donde Veeam no llegaba por limitaciones de arquitectura, la automatización permitió no dejar ningún sistema sin protección. Toda la base técnica quedó documentada y disponible para el área de operaciones y auditorías futuras.

De backups de VM a resiliencia transaccional: SQL Server AlwaysOn + Veeam Application-Aware Processing

Teníamos 35 bases de datos SQL Server “protegidas”. Hasta que nos dimos cuenta de que no lo estaban.
Backups a nivel de imagen de VM y tareas aisladas en SQL Management Studio: el sistema parecía funcionar, pero sin consistencia transaccional, una “foto” de una VM activa no garantiza una recuperación limpia. Algunas bases críticas directamente no tenían estrategia de backup definida.

Antes — riesgo real

• →Backup a nivel de imagen VM sin quiesce transaccional
• →Tareas SQL manuales no coordinadas con el backup
• →Bases críticas sin política definida
• →Riesgo latente de pérdida de datos ante cualquier falla

Arquitectura implementada

Nodo primario: backup completo + truncamiento de logs.
Nodo secundario: política Copy-Only para preservar la cadena de logs intacta.

Desafíos técnicos resueltos en entornos AlwaysOn

• →Log chain break en réplicas secundarias: resuelto configurando políticas Copy-Only en los nodos secundarios, preservando la integridad de la cadena de logs.
• →Conflictos de truncamiento de logs: responsabilidad delegada exclusivamente a la réplica primaria, eliminando inconsistencias entre nodos del grupo de disponibilidad.

Resultado — Veeam Explorer for SQL Server

La parte técnica fue la más corta del proyecto. El verdadero desafío fue coordinar los equipos de DBA e infraestructura y tener cada decisión validada antes de tocar producción.

Este fin de semana todos mis sitios se cayeron en producción. ¡Y la culpa fue mía!

Tengo un VPS con varios sitios corriendo en Docker detrás de un reverse proxy nginx con acme-companion para los certificados Let’s Encrypt automáticos. Un fin de semana intenté darle más seguridad al webhook de mi chatbot (ATH) — quería limitar los requests por IP para evitar abusos. Configuré el rate limiting, reinicié el proxy y… connection refused en todos mis dominios. DNS resolviendo bien ✅  contenedores corriendo ✅  puertos escuchando ✅  incluso desde adentro del contenedor el sitio respondía. Todo parecía estar bien y sin embargo nada cargaba.

El error que lo rompió todo

Fui capa por capa hasta llegar a los logs del reverse proxy. Miles de líneas del mismo error en loop:

La directiva limit_req_zone debe vivir en el contexto http de nginx, no dentro de un bloque server. Yo la puse en /etc/nginx/vhost.d/matiascanteros.site, que nginx incluye dentro del contexto server de cada virtual host. nginx valida toda la configuración antes de arrancar y, si encuentra un error en cualquier archivo, el proceso no levanta. Una sola línea mal puesta, todo abajo.

La solución correcta

Mover la definición de la zona al contexto correcto — un archivo custom.conf dentro del volumen conf.d montado desde el host — y dejar solo el uso puntual en el virtual host del chatbot:

Lo que me llevo

• ✔nginx lee toda la configuración antes de arrancar — un error en cualquier archivo incluido tira el proceso entero, sin importar a qué virtual host pertenezca.
• ✔En nginx, el scope importa: declarar una zona (limit_req_zone) es diferente a usarla (limit_req). La definición va en http, la aplicación en location.
• ✔En infraestructura no se adivina, se descarta: DNS → puertos → proxy → backend. Los logs dicen la verdad antes que cualquier suposición.

La parte técnica fue la más corta del debugging. El valor real estuvo en entender por qué fallaba — no solo corregirlo — y en descubrir una oportunidad de mejorar la arquitectura del proxy montando conf.d como volumen para separar la configuración global de la de cada virtual host.