En el mundo del self-hosting y los homelabs, las copias de seguridad suelen empezar con buenas intenciones… y acabar en un script olvidado. No por falta de herramientas potentes, sino por falta de operativa: programación, seguimiento, retención, repositorios, y —sobre todo— visibilidad. En ese hueco quiere encajar Zerobyte, un proyecto que se presenta como una plataforma de automatización de backups con interfaz web, construida encima de Restic, y pensada para planificar, gestionar y monitorizar copias cifradas en distintos backends.
La propuesta es directa: Restic ya es un “motor” de copias moderno y seguro (incremental, con uso cuidadoso de criptografía y posibilidad de verificación de restauración), pero su naturaleza de CLI hace que muchas tareas de operación diaria recaigan en quien lo administra. Zerobyte intenta poner orden: un panel, trabajos programados, políticas de retención y una forma unificada de tratar orígenes y destinos.
Qué es exactamente Zerobyte (y por qué no es “otro backup más”)
Zerobyte no pretende reinventar el concepto de backup: se apoya en Restic como base y construye una capa de gestión por encima, con foco en automatización. En la práctica, eso significa:
- Backups automatizados con cifrado, compresión y políticas de retención, utilizando Restic por debajo.
- Programación flexible de tareas y control de retención desde la interfaz.
- Soporte de múltiples orígenes, incluyendo directorios locales y, si se habilita el modo con montajes, recursos remotos como NFS/SMB/WebDAV.
- Repositorios que pueden vivir en disco local o en servicios tipo S3, GCS, Azure o remotos vía rclone.
El matiz importante: no es solo “una UI bonita”. Su valor está en que te obliga a pensar en términos de “volúmenes”, “repositorios” y “jobs” con horarios y retención, que es justo lo que suele fallar cuando todo depende de un par de comandos manuales.
Un despliegue rápido… con advertencias serias de seguridad
Zerobyte se despliega con Docker/Docker Compose y expone la interfaz en el puerto 4096. El ejemplo típico usa una imagen publicada en GHCR y un volumen persistente para su estado:
services:
zerobyte:
image: ghcr.io/nicotsx/zerobyte:v0.19
container_name: zerobyte
restart: unless-stopped
cap_add:
- SYS_ADMIN
ports:
- "4096:4096"
devices:
- /dev/fuse:/dev/fuse
environment:
- TZ=Europe/Paris
volumes:
- /etc/localtime:/etc/localtime:ro
- /var/lib/zerobyte:/var/lib/zerobyte
Lenguaje del código: JavaScript (javascript)Aquí viene lo relevante para un medio de sistemas: el propio proyecto desaconseja ejecutarlo en un servidor accesible directamente desde Internet. Si aun así se hace, la recomendación es bindear a localhost (por ejemplo 127.0.0.1:4096:4096) y entrar mediante un túnel seguro (SSH, Cloudflare Tunnel, etc.).
También advierte de forma explícita: no apuntar /var/lib/zerobyte a un recurso de red, por problemas de permisos y degradación de rendimiento.
Y hay un tercer punto que, en entornos corporativos, suele encender todas las alarmas: para montar recursos remotos desde la propia herramienta, el contenedor puede requerir SYS_ADMIN y acceso a /dev/fuse, algo que eleva la superficie de riesgo (capacidades extra dentro del contenedor). Zerobyte propone un “modo simplificado” sin esos privilegios si solo vas a respaldar rutas ya montadas localmente.
Tabla rápida: Zerobyte vs Restic “a pelo”
| Aspecto | Restic (CLI) | Zerobyte (capa sobre Restic) |
|---|---|---|
| Enfoque | Motor de backup y restauración | Orquestación + panel web |
| Programación | Cron/systemd (lo montas tú) | Scheduler integrado en la app |
| Visibilidad | Logs/salida por consola | Gestión/monitorización en interfaz |
| Backends de repositorio | Muchos tipos (según Restic) | Local, S3/GCS/Azure, rclone (según el proyecto) |
| Montaje de shares remotos | Lo resuelves fuera (mount del SO) | Puede montar con FUSE/privilegios o trabajar con rutas ya montadas |
| Superficie de ataque | Depende de tu entorno | Ojo si expones web y/o habilitas SYS_ADMIN/FUSE |
El “punto dulce” para sysadmins: homelab serio, pymes y servidores con muchas piezas
Zerobyte encaja especialmente bien en escenarios donde:
- Hay varias fuentes de datos (NAS, shares, carpetas de servicios, volúmenes Docker) y se quiere una política coherente.
- Se necesita rotación/retención sin estar peleando con scripts.
- Se quiere un “centro de mando” que permita comprobar en un vistazo qué ha corrido, qué falló y cuándo fue la última copia.
En cambio, para un servidor crítico expuesto, o para entornos con requisitos estrictos, el debate cambia: la interfaz web y las capacidades extra (si montas remotos desde dentro) obligan a aplicar el mismo rigor que aplicarías a cualquier panel de administración.
Recomendaciones prácticas para desplegarlo sin sustos
- No lo publiques en Internet. Si necesitas acceso remoto, enlázalo a
127.0.0.1y entra con túnel autenticado. - Evita privilegios si no te hacen falta. Si solo vas a respaldar directorios locales ya montados, usa el modo sin
SYS_ADMINni/dev/fuse. - Persistencia en disco local. Mantén
/var/lib/zerobyteen almacenamiento local fiable; no en shares de red. - Piensa en restauración desde el minuto cero. Restic pone énfasis en la verificabilidad de poder restaurar; traslada esa mentalidad a Zerobyte: prueba restores parciales y valida tiempos.
Preguntas frecuentes
¿Zerobyte sustituye a Restic?
No: Zerobyte se apoya en Restic como motor de copias. La idea es aportar gestión, programación y monitorización por encima.
¿Puedo usar Zerobyte para copias a S3 o a un almacenamiento tipo “cloud”?
Sí. El proyecto contempla repositorios en local y en servicios tipo S3, además de otros como GCS, Azure o remotos vía rclone.
¿Es seguro exponer Zerobyte en un VPS con el puerto abierto?
El propio proyecto lo desaconseja y sugiere, si hace falta acceso remoto, limitarlo a localhost y usar un túnel seguro con autenticación.
¿Qué implicaciones tiene usar SYS_ADMIN y FUSE en el contenedor?
Aumenta privilegios/capacidades del contenedor para poder montar shares remotos directamente desde Zerobyte. Si no necesitas esa función, el “setup simplificado” evita ese extra de permisos.
