Azure DevOps backup tool

Hace unos meses me empezó a preocupar algo evidente y sin embargo invisible: que sucede si tu código vive solo en Azure DevOps. Repositorios, pipelines, wikis. Si mañana Microsoft tuviera un mal día — o nuestra cuenta uno peor — perderíamos años de trabajo. Y aunque Microsoft tiene SLAs estupendos, «tener una copia de tu propio código en tu propia casa» no es paranoia: es higiene básica.

Por eso he liberado ADO Backup Tool, una herramienta dockerizada que hace exactamente eso: backup automático y desatendido de Azure DevOps a un volumen local (o a tu NAS). El código está en GitHub bajo licencia MIT.

Qué hace

Un único contenedor que corre permanentemente en tu NAS (o en cualquier máquina con Docker). Internamente lleva un planificador cron y, en cada ejecución, vuelca tres cosas:

• Repositorios Git como bare mirrors (git clone --mirror), con actualización incremental — no reclona el historial entero cada noche.
• Definiciones de pipelines (build y release) exportadas como JSON individuales.
• Wikis con sus metadatos y todas las páginas en markdown.

Todo el comportamiento se controla con un único config.yaml de unas 25 líneas: qué organización, qué proyectos (o ["*"] para todos), cuándo correr (cron estándar), cuántos días retener, qué recursos incluir.

Por qué bare mirrors y no checkouts

La decisión menos obvia del proyecto. Un git clone --mirror guarda toda la base de datos de git — ramas, tags, historia completa — sin desplegar el árbol de trabajo. Ocupa menos, no se rompe si alguien toca archivos por accidente, y permite restaurar cualquier commit, cualquier rama, en el momento que quieras:

git clone /backup/2026-05-21T020000/Project1/git/RepoA.git restaurado
cd restaurado
git checkout main

Y los runs sucesivos son rápidos: el bare mirror anterior se copia adelante y se refresca con git remote update, que solo descarga los objetos nuevos.

Despliegue en QNAP Container Station

Yo lo ejecuto en un QNAP por SMB ACLs y por la conveniencia de tener los backups en el mismo NAS donde ya orquesto todo lo demás. El repo incluye un docker-compose.qnap.yml específico, con paths /share/ y un par de detalles que aprendí por las malas:

• Container Station tiene una directiva build: que construye la imagen automáticamente desde el Dockerfile en una shared folder — no hace falta SSH. Solo pegar el YAML en Create → Application.
• Los env_file: con un .env adyacente no funcionan en Container Station porque CS copia el compose a su directorio interno y no arrastra el .env sibling. Hay que usar ruta absoluta… o aceptar que el PAT vive en el YAML con permisos SMB restringidos. Esto último es lo que el README documenta con honestidad.
• El contenedor corre como root dentro de Docker — por diseño — para no pelearse con permisos UID/GID de QNAP. El control de acceso vive en los ACLs de SMB, no dentro del contenedor.

Primer run, en producción

En mi caso, 5 repos + 6 pipelines de 3 proyectos completaron el primer backup en 28 segundos, con 0 errores. A partir de la segunda ejecución los repos ya respaldados pasan a modo incremental.

[INFO] backup run started -> /backup/2026-05-21T100033
[INFO] git: Project1/repo-a backed up (full clone, 4.4 MB, 2.8s)
[INFO] pipelines: Project1 build definitions saved (6)
[INFO] git: Project2/repo-b backed up (full clone, 145 KB, 1.2s)
[INFO] backup run finished in 28.0s — repos=5 pipelines=6 wikis=0 errors=0
[INFO] scheduler started — next run at 2026-05-22 02:00:00+02:00

Lo que NO hace (v1.0)

Por honestidad, una lista de cosas que están fuera de alcance en esta primera versión:

• Work items, artefactos y test plans.
• Restore/import automatizado (la restauración hoy es manual con git clone desde el mirror — funciona perfectamente, simplemente no hay un comando «restore»).
• Multi-organización (un contenedor = una org; si tienes varias, levantas varios contenedores).
• Autenticación que no sea PAT.
• Repositorios TFVC (solo Git).

Documentación bilingüe

El repo viene con README en inglés y español. Ambos cubren PAT scopes, configuración, despliegue en QNAP, formato de salida y restauración.

Contribuir

Issues y pull requests son bienvenidos. Hay 20 tests pytest cubriendo config, cliente HTTP de ADO, runner, y cada uno de los backupers (git, pipelines, wikis). Si te animas, mantén el verde antes de abrir PR.

Licencia MIT. Código: github.com/mainmind83/ado-backup