DEV Community: Nicole Rios

Por qué no usamos MS SQL Server: seis estrategias de respaldo que sí se pueden verificar

Nicole Rios — Sun, 04 Oct 2026 04:28:41 +0000

Por qué no usamos MS SQL Server: seis estrategias de respaldo que sí se pueden verificar

El enunciado pedía estrategias de copia de seguridad excluyendo MS SQL Server.
En nuestro equipo la exclusión seßeumplió en el código, no solo en el texto: la API
rechaza cualquier motor que no sea MongoDB, Redis o Neo4j, y hay un caso de
prueba que lo comprueba.

Pero dejar SQL Server fuera es la parte fácil. Lo difícil resultó ser la otra
pregunta: ¿qué estrategia de respaldo puedes verificar de verdad?

Los enlaces del proyecto

Repositorio público con el código, la suite y el índice de respaldos: https://github.com/dejameingresar/dataforge-backup-nosql
Aplicación desplegada en la nube (Render, creada desde render.yaml): https://dataforge-backup-si783.onrender.com
Artículo complementario del equipo: Seis estrategias de respaldo para bases de datos NoSQL, y qué falla de verdad

La exclusión, aplicada de verdad

SQL Server no aparece en ninguna decisión de diseño del proyecto. Aparece en dos
lugares, y en los dos para rechazarlo:

# app/tests/casos.py — el motor prohibido tiene que dar 400, no 500
for motor in ("", "postgres", "MONGODB", "mssql"):
    ...
# smoke.py — "un motor prohibido (MS SQL Server) se rechaza con 400"
estado, cuerpo = post(f"{url}api/respaldar/mssql/completo")

Eso no es simbólico. Significa que la API tiene una noción de "motor no
soportado" separada de "motor caído", y que un error de usuario siempre devuelve
400 en lugar de romper el servidor.

Por qué no MS SQL Server: cuatro razones que se comprobaron

No lo excluimos por gusto ni por mods. Lo excluimos porque su modelo de respaldo
no encaja con lo que este proyecto tenía que demostrar.

1. El respaldo de SQL Server depende de una instancia viva, y su artefacto
depende de la versión que lo creó. Un .bak se genera con BACKUP DATABASE y
se restaura con RESTORE, pero el archivo lleva la versión del motor que lo
produjo: restaurarlo exige una edición compatible. En un proyecto cuyo objetivo
es que el respaldo sobreviva a la caída del motor, depender de que el motor
volvió con la misma edición es una restricción que no se puede verificar desde
fuera.

2. Su automatización exige más superficie que un solo binario. Un respaldo
programado de SQL Server necesita la instancia, las credenciales, un destino
escribible y la tarea configurada. Las seis estrategias que implementamos se
ejecutan con un comando cada una:

mongodump --uri mongodb://127.0.0.1:27017/dataforge_backup --out DIR --gzip
redis-cli -p 6379 --rdb dump.rdb
neo4j-admin database dump neo4j --to-path=DESTINO

Una estrategia que necesita cuatro piezas coordinadas no se puede probar en un
for loop. Una que necesita un comando, sí.

3. No tiene equivalente conceptual de "copia en frío del almacenamiento".
Las estrategias físicas que sí implementamos —copiar los archivos del motor con
el servicio detenido— no existen como operación propia en SQL Server: el
.mdf, los archivos de log y el backup son cosas distintas y la foto del
almacenamiento no es una operación respaldada por el motor. La distinción
lógico/físico es justamente la que queríamos poder comparar.

4. Los seis compromisos que medimos no aplican a un motor relacional. Cada
restricción que encontramos es del motor NoSQL, y son las que hacen un respaldo
interesante de estudiar:

Compromiso	Dónde aparece
`mongorestore` no acepta un directorio: con la carpeta restaura 0 documentos y devuelve código `0`	MongoDB
`CONFIG SET dir` falla con `can't set protected config`; hay que usar `redis-cli --rdb`	Redis 7
`SET n:Etiqueta` es error de sintaxis sin el plugin APOC	Neo4j 5
`MERGE` colapsa aristas repetidas entre el mismo par de nodos	Neo4j
Community exige el motor detenido para `database dump`	Neo4j
`database backup` no existe en Community (es de Enterprise)	Neo4j

Ninguno de esos compromisos tiene equivalente en el modelo relacional. Son
precisamente los que hacen que "verificar un respaldo" no sea sin automático.

El hallazgo que ningún manual avisa: el respaldo que "tiene éxito" y no restaura nada

Este es el resultado que más aporta del proyecto, y no aparece en la
documentación.

mongorestore no acepta el directorio del dump. Si se le pasa la carpeta
completa, imprime un mensaje apodbable:

don't know what to do with file ... skipping...

…restaura cero documentos y sale con código de salida 0.

Es el peor fallo posible en un respaldo: parece un éxito. Un pipeline que
comprueba el código de salida registra un respaldo íntegro que no contiene nada.

La única forma de detectarlo es contar lo que vuelve. Por eso el ciclo de
prueba del proyecto es siempre el mismo, sin excepción:

se genera el respaldo;
se mide su SHA-256;
se destruyen los datos;
se restaura;
se cuenta lo que volvió.

Ese quinto paso es el que separa un respaldo de una intención.

Seis estrategias, medidas

Cada número de esta tabla salió de una corrida real. El artefacto se vuelve a
leer desde disco para medirlo y para hashearlo.

Motor	Estrategia	Artefacto	Tamaño	Round-trip medido
MongoDB	`logico_mongodump`	`*.bson.gz`	30.8 KiB	1400 → 1400 docs
MongoDB	`fisico_wiredtiger`	copia del `dbpath`	1.11 MiB	1400 → 1400 docs
Redis	`rdb_dump`	`dump.rdb`	11.3 KiB	240 → 240 claves
Redis	`aof_append`	`appendonlydir/`	11.4 KiB	240 → 240 claves
Neo4j	`dump_binario`	`neo4j.dump`	509.1 KiB	200/594 → 200/594
Neo4j	`exportacion_cypher`	JSON Lines	104.0 KiB	200/594 → 200/594

6 de 6 restauraron exactamente lo que había.

Una advertencia sobre esas cifras: son de una sola ejecución en una máquina de
escritorio (Linux 6.8, Python 3.11.15). Sirven para comparar estrategias entre
sí, no como referencia de un servidor en producción. El propio índice de
respaldos lo declara.

La physical es más rápida de escribir y te quita el servicio

Las dos estrategias físicas —fisico_wiredtiger y dump_binario— exigen el
motor detenido. En producción eso no es un detalle de implementación: es una
decisión de arquitectura, porque significa una ventana sin servicio.

Para la misma base de grafos, la exportación lógica corría en caliente:

Estrategia Neo4j	Duración	¿Motor encendido?
`exportacion_cypher` (JSON Lines)	420 ms	Sí
`dump_binario` (`.dump`)	3.48 s	No

Ocho veces más rápida, pero con el servicio caído. Elijes según qué te duele
más.

La tentación que casi arruinó el proyecto

MERGE funde en una sola las aristas repetidas entre el mismo par de nodos con
propiedades distintas. Al medir el round-trip faltaban 4 relaciones: 590 de
594.

590 de 594 parece "casi bien". Ese es el momento exacto en que un respaldo mal
verificado se convierte en un respaldo mal documentado: bastaba relajar la
comparación un 0.7 % para que el número cuadrara y el defecto quedara oculto.

La tentación era relajar el umbral. Convertir un defecto real en un falso
positivo es exactamente lo que hace que un sistema de respaldo pierda
credibilidad. Con CREATE en lugar de MERGE, las 594 se conservan.

Qué no protege cada estrategia

Esta tabla es la que más útil resulta y la que menos se documenta. Una estrategia
que solo declara ventajas no está documentada, está vendida.

Estrategia	Qué protege	Qué NO protege
Completo	Todo el contenido, sin depender de nada anterior	La caída del disco que lo contiene; un borrado posterior
Incremental	Lo que cambió desde el último completo	Depende encadenadamente de todos los completos: falta uno y se rompe la cadena
Diferencial	Lo que cambió desde el último de su misma estrategia	Los cambios acumulados desde el completo
Instantánea	El estado en un instante, sin detener el motor	Corrupción posterior del archivo; exige almacenamiento transaccional
Replicación	Disponibilidad continua: otra copia siempre viva	No protege contra el borrado: un `DROP` se replica al instante

La última fila es la más contraintuitiva. Replication se suele vender como
respaldo y no lo es: multiplica la disponibilidad y duplica el error.

Verificación y despliegue automatizado

La suite (app/tests/casos.py, casos T-01..T-27) corre en cada push mediante
.github/workflows/pruebas.yml, y la aplicación se crea sola en Render leyendo
render.yaml,
con autoDeploy y health check en /api/salud.

Hay un punto que conviene decir con claridad: los casos que necesitan motores
reales no pueden correr en el runner de GitHub Actions. El runner no tiene
MongoDB, Redis ni Neo4j. La suite no inventa un resultado: esos casos fallan de
forma explícita y la verificación completa se hace contra los motores locales.

Es la misma lección del otro proyecto del equipo: un n/d en la pantalla es
correcto; un test verde sin motor detrás no lo sería.

En el despliegue público los tres motores aparecen como n/d, porque un servicio
público no expone puertos de base de datos. El despliegue demuestra que la
aplicación arranca y responde; las cifras medidas son del laboratorio.

Conclusiones

Un respaldo no es un archivo: es una cadena. Backup, verificación por hash, restauración y conteo. Se salta un eslabón y el resultado no sirve.
El código de salida no es evidencia. Los dos fallos más caros de este proyecto salían con 0. Contar lo que volvió sí lo es.
La verificación tiene que ser estricta o no vale nada. Relajar el umbral de comparación convierte un defecto real en un falso positivo.
Cada familia de motor tiene su propia restricción, y documentar qué no protege una estrategia es más útil que enumerar qué sí.
Excluir una tecnología se demuestra en el código. En este proyecto, SQL Server está en la lista de motores rechazados y hay una prueba que lo verifica, no una nota en el README.

Y el punto que resume todo lo demás: elegir una tecnología obliga a aceptar sus
compromisos. Elegimos estos tres motores porque sus límites son comprobables
con un comando y un count. Ahí es donde se puede demostrar que un respaldo
funciona, en vez de suponerlo.

Los bugs más caros del escaneo de vulnerabilidades no están en el código, están en el pipeline

Nicole Rios — Sun, 04 Oct 2026 04:22:24 +0000

Los bugs más caros del escaneo de vulnerabilidades no están en el código, están en el pipeline

En los laboratorios de la unidad revisamos código con SonarQube, Semgrep, Snyk y
tfsec. Para esta actividad cambiamos el punto de mira: OWASP Dependency-Check
(dependencias de terceros, base de avisos de la OWASP Foundation) y gosec
(análisis estático de Go con reglas mapeadas a CWE). Ninguna de las dos se usó en
los laboratorios.

La parte interesante no fue el informe final. Fue lo que pasó al intentar que el
escaneo se repitiera solo en cada push.

Los enlaces del proyecto

Repositorio público con el código, los workflows y el informe: https://github.com/UPT-FAING-EPIS/actividad-grupal-1-sast
Informe de SAST publicado como aplicación web (Vercel, despliegue por GitHub Actions): https://sast-taskflow-iota.vercel.app
Artículo complementario del equipo: Auditar dependencias con OWASP Dependency-Check

El resultado que importa

La aplicación de caso de estudio (app/main.go) está escrita a propósito con
las clases de fallo más comunes. Es un objetivo de prueba, no una aplicación de
producción.

gosec -no-fail -fmt=json -out=informe.json ./...

Severidad	Cantidad
HIGH	5
MEDIUM	11
LOW	1
Total	17

Cinco de los altos son una credencial escrita en el código, una clave privada RSA
embebida, y tres encontrados por análisis de taint (inyección de comandos,
recorrido de rutas, XSS), que no aparecen buscando palabras clave: la herramienta
sigue el valor desde que entra en la función hasta donde se usa.

Ese 17/5/11/1 es el mismo número que produce el escaneo manual y el que produce
el pipeline. Que coincidan no es casualidad: es la comprobación de que el
automatismo está escaneando lo mismo que la persona.

El fallo más caro: un escaneo que no ocurrió pareciendo limpio

gosec no necesita el compilador de Go para no fallar. Sin él, el comando
termina con código de salida 0 y escribe:

Archivos: 0 | Lineas: 0 | Hallazgos: 0

Eso es indistinguible de "el código no tiene nada". Un panel que muestra una
casilla verde y un 0 no está diciendo que el código sea seguro: está diciendo que
no miró nada.

Esto lo sufrimos de verdad. Corregimos el workflow para que escaneara
./app/..., lo subimos, y el paso pasó en verde. El informe, en cambio, decía
cero hallazgos. La causa: go.mod vive en app/, no en la raíz del
repositorio, así que al ejecutar gosec desde la raíz no había módulo que
resolver y el analizador no tenía nada que cargar:

# mal: sin modulo en la raiz, gosec responde "Files: 0" sin explicar por que
- run: gosec -no-fail -fmt=json -out=informe.json ./app/...

# bien: hay que escanear desde el directorio del modulo
- name: Escanear
  working-directory: app
  run: gosec -no-fail -fmt=json -out="$GITHUB_WORKSPACE/informe.json" ./...

La corrección que de verdad importa no es el working-directory. Es no trusting
el cero:

if not iss:
    raise SystemExit("::error::0 hallazgos: el escaneo no ocurrio, no salio limpio")

Un escaneo con cero hallazgos y un escaneo que no se ejecutó producen el mismo
archivo. Si el pipeline no los distingue, no está midiendo nada: está
decorándose. Y una automatización que miente es peor que no tener automatización,
porque ocupa el lugar de una revisión.

Los otros cuatro fallos, todos de automatización

Ninguno estaba en el código de la aplicación. Los cuatro estaban en el pipeline.

1. El workflow estaba escrito para otro proyecto. El security.ymlapuntaba
dotnet restore TaskFlow.Api/TaskFlow.Api.csproj sobre un repositorio que no
tenía ese proyecto, y escaneaba seguridad/banco-vulnerable/, un directorio que
tampoco existía. El error que salía era MSBUILD : error MSB1009: Project file does not exist, que señala un problema de rutas pero no dice que el archivo de
workflow está describiendo otro repositorio. Cuatro ejecuciones seguidas en rojo
por lo mismo.

2. Una acción que dejó de existir. El job de tfsec usaba
aquasecurity/tfsec-action@v1, y el runner respondió Unable to resolve action aquasecurity/tfsec-action@v1, unable to find version v1. Las etiquetas de las
acciones son referencias: pueden desaparecer, y cuando lo hacen el job no falla
por código, falla al no resolverse.

3. Un secret ausente que se veía como otro problema. El despliegue ejecutaba

npx vercel deploy --prod --yes --token ""

con VERCEL_TOKEN sin registrar, y la CLI respondía Error: You defined "--token", but it's missing a value. Un mensaje que habla de sintaxis de
comandos cuando el problema es de configuración. La versión que obliga a nombrar
el secreto que falta:

- name: Verificar secrets de Vercel
  env:
    VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }}
    VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
  run: |
    for v in VERCEL_TOKEN VERCEL_ORG_ID; do
      if [ -z "${!v}" ]; then
        echo "::error::Falta el secret $v (Settings > Secrets > Actions)"
        exit 1
      fi
    done

4. Un .gitignore que se comió un resultado. El .gitignore traía
informe.json, el mismo nombre que produce el escaneo. El artefacto se generaba,
se subía, y desaparecía antes de llegar a ninguna parte.

Lo que la automatización no puede hacer sola

Dos cosas de este ejercicio quedan fuera del alcance de un pipeline, y conviene
decirlo en vez de dejarlas para cuando falle.

La base de avisos de la NVD no cabe en un runner. Dependency-Check descarga
la base de la NVD, que supera los 400.000 registros. Sin una API key la descarga
inicial tarda horas; con una key gratuita baja a minutos
(https://nvd.nist.gov/developers/request-an-api-key). En un job con límite de
tiempo, la primera ejecución nunca va a completar. Lo que decidimos fue no
inventar el resultado: si el informe no existe, el workflow escribe la constancia
y lo dice con un ::warning:: en vez de publicar un cero. Registrando el secret
NVD_API_KEY, el escaneo real se completa sin tocar el workflow.

Las métricas solo existen si alguien las midió. El artefacto informe-gosec.json
está versionado en el repositorio, con fecha y entorno, precisamente para que el
número que se cita en el artículo se pueda contrastar contra el archivo. Un
escaneo que corre y nadie guarda no deja nada que revisar.

Publicar el informe, no solo el código

El informe de escaneo sirve poco si leerlo exige clonar el repositorio y abrir un
JSON. El segundo workflow corre el mismo gosec en cada push a web/** y publica
el resultado como aplicación web en Vercel, con el detalle por severidad y regla.

El detalle que costó encontrar: la CLI de Vercel no recibe el proyecto por
variables de entorno. Las lee de web/.vercel/project.json. Con solo --token
y --scope el comando responde You specified VERCEL_PROJECT_ID but you forgot VERCEL_ORG_ID, o peor, despliega en un proyecto que no es el que creías. El
workflow ahora escribe ese archivo con los secrets:

mkdir -p .vercel
printf '{"projectId": "%s", "orgId": "%s"}\n' "$VERCEL_PROJECT_ID" "$VERCEL_ORG_ID" > .vercel/project.json
npx --yes vercel@25 deploy --prod --yes --token "$VERCEL_TOKEN"

Limitación honesta

Automatizar el escaneo garantiza que se repita, no que acierte. Estas
automatizaciones se ejecutan en cada push, en cada pull request y una vez por
semana, porque la base de avisos cambia a diario y una vulnerabilidad puede
publicarse después del último push. Aun así:

Un análisis estático no ve lógica de negocio incorrecta si no hay un patrón peligroso detrás. La base de este ejercicio lo demuestra: una aplicación deliberadamente insegura en clase de datos, pero sin ninguna regla de las que busca gosec, daría un informe limpio sin tener un solo problema resuelto.
El caso de estudio no se despliega y no debe usarse con datos reales. Publicar el informe es seguro; publicar la aplicación vulnerable, no.
gosec solo analiza Go. Sobre un proyecto en C# devuelve Files: 0, que es el mismo cero sin información del que hablaba antes.

Conclusiones

El escaneo que no se ejecutó y el escaneo limpio producen el mismo archivo. La primera defensa no es la herramienta, es un paso que compare 0 contra "no se pudo ejecutar" y aborte si no puede distinguirlos.
En un pipeline, la mayoría de los fallos son de rutas, de secretos y de versiones, no de vulnerabilidades. Ninguno de los cuatro fallos de este artículo estaba en el código de la aplicación.
Un mensaje de error que no nombra la causa cuesta más que el fallo. El missing a value de Vercel ocultaba un secret sin registrar durante una ejecución completa.
Un resultado sin su archivo no es evidencia. Versionar el informe con fecha y entorno es lo que permite que alguien lo contraste en lugar de creerlo.
La automatización multiplica el valor de un control, y también multiplica el alcance de un error de configuración. Un escaneo manual equivocado se detecta en la revisión. Un escaneo automático que no escanea pasa desapercibido mientras todo luzca verde.

Lo que queda fuera de alcance, y no es menor: la base de avisos completa no cabe
en un runner sin API key. Un análisis de dependencias que no puede descargar la
base de datos no es un análisis de dependencias, y conviene que el pipeline lo
diga en lugar de mostrar un cero.