---
title: "Zerobyte, la GUI de Restic: automatización de copias de seguridad autoalojadas (2026)"
description: "Despliega Zerobyte, la interfaz gráfica open source de Restic para copias de seguridad autoalojadas. Docker Compose y Dokploy, claves de recuperación, repositorios espejo y consejos de restauración (2026)."
date: 2026-10-22
categories: ["self-hosting"]
tags: ["restic","backup","docker"]
---
import Button from "@components/widgets/Button.astro";
import Notice from "@components/widgets/Notice.astro";
import ListCheck from "@components/widgets/ListCheck.astro";
import Accordion from "@components/widgets/Accordion.astro";
import Tabs from "@components/widgets/Tabs.astro";
import Tab from "@components/widgets/Tab.astro";
import YouTubeEmbed from "@components/widgets/YouTubeEmbed.astro";
Si administras un VPS, un homelab o cualquier servidor Linux, las copias de seguridad son el único seguro que importa. Los discos fallan, las actualizaciones rompen cosas y los errores ocurren. Zerobyte es una GUI de Restic que coloca un panel web limpio encima de [Restic](https://restic.net/), así obtienes automatización de copias de seguridad autoalojadas sin vivir en la terminal.
El proyecto ha avanzado rápido. Cuando esta guía se publicó por primera vez la imagen era `v0.19`; la línea estable actual es `v0.43.2` con más de 7.000 estrellas en GitHub, un sitio de documentación en [zerobyte.app](https://zerobyte.app/docs) y más de 20 versiones estables de por medio. El flujo de trabajo central no ha cambiado: volúmenes, repositorios, trabajos programados, retención y restauraciones. Los detalles operativos sobre claves, variables de entorno y exposición cambiaron mucho. Esta actualización cubre la versión actual de principio a fin, incluidas las partes que te van a doler si solo subes la etiqueta de la imagen en un stack antiguo.
## ¿Qué es Zerobyte?
[Zerobyte](https://github.com/nicotsx/zerobyte) es una plataforma open source (AGPL-3.0) de automatización de copias de seguridad que envuelve el motor de Restic con un panel moderno. Gestiona la creación de repositorios, la programación, la retención y los flujos de restauración desde un navegador en lugar de un montón de trabajos cron y alias de shell.
Piensa en él como una interfaz web de Restic con un programador incorporado. El trabajo pesado —cifrado, deduplicación, formato del repositorio— sigue siendo de Restic. Zerobyte es el plano de control encima.
### Por qué funciona Restic junto con Zerobyte
| Capa | Responsabilidad | Lo que obtienes |
| --- | --- | --- |
| Restic | Cifrado, deduplicación, compresión, formato del repositorio | Copias de seguridad seguras y eficientes |
| Zerobyte | Interfaz web, programación, retención, espejos, registros | Un plano de control usable |
Juntos te dan copias de seguridad rápidas y cifradas con un flujo de trabajo que puedes retomar meses después y seguir entendiendo. Si Zerobyte desapareciera mañana, tus repositorios seguirían siendo repositorios Restic normales que puedes leer con la CLI estándar y la clave de recuperación.
### Características principales
- Copias de seguridad automatizadas con políticas de retención impulsadas por Restic
- Cifrado de extremo a extremo por defecto, con claves gestionadas mediante un flujo de clave de recuperación
- Programaciones flexibles, además de ejecuciones bajo demanda con «Backup now» sin tocar cron
- Reintentos automáticos con cantidad y retardo configurables; los trabajos interrumpidos se reencolan tras un reinicio
- Repositorios multibackend: locales, compatibles con S3, GCS, Azure y remotos de rclone
- Volúmenes de origen desde directorios locales, NFS, SMB, WebDAV y SFTP
- Repositorios espejo para configuraciones 3-2-1, con relleno y progreso de sincronización en la interfaz
- Modos de compresión `off` / `auto` / `max`, con anulación por trabajo y flags personalizados de Restic
- Descargas de snapshots desde el navegador, restauraciones cancelables y restauración en una ubicación personalizada
- Organizaciones multiusuario, 2FA, passkeys, SSO con OIDC y claves de API con caducidad
- Registros de trabajos, una página de Actividad para operaciones en segundo plano y estado de salud de las notificaciones
Zerobyte sigue en la serie 0.x. Muchas versiones se publicaron en 2026 y varias fueron disruptivas: nuevas variables de entorno obligatorias, una lista blanca de webhooks y la eliminación de la sintaxis de referencias a secretos. Fija la etiqueta de tu imagen, lee las notas de la versión antes de actualizar y espera que la interfaz se mueva entre versiones menores.
## Qué ha cambiado desde nuestra primera guía
Si desplegaste desde la versión de 2025 de este artículo, esto es lo que importa antes de tocar nada.
Si desplegaste con nuestra guía de 2025: mover la imagen de `v0.19` a `v0.43` por sí solo NO arrancará el contenedor. `APP_SECRET` es obligatorio desde v0.23.0 y `BASE_URL` desde v0.24.0. Añade ambas y luego actualiza. Consulta [La clave de recuperación y APP_SECRET](#la-clave-de-recuperación-y-app_secret-tus-claves-reales) y [Cómo actualizar Zerobyte de forma segura](#cómo-actualizar-zerobyte-de-forma-segura).
Versión corta de los cambios:
- **La imagen ahora es `ghcr.io/nicotsx/zerobyte:v0.43`** (`v0.43.2` estable al 2026-10-03). El antiguo pin `v0.19` está unas 24 versiones estables por detrás.
- **Dos variables de entorno obligatorias.** `APP_SECRET` (desde v0.23.0) cifra los secretos guardados en la base de datos. `BASE_URL` (desde v0.24.0) debe ser la URL real que usas para abrir la interfaz; un prefijo `https://` activa las cookies Secure.
- **Modelo de clave de recuperación para las contraseñas de repositorio.** Los repositorios creados en la interfaz los inicializa Zerobyte con una contraseña de Restic a nivel de organización que descargas una vez como `restic.pass`. Ya no inventas tú esa contraseña.
- **Repositorios espejo.** Zerobyte ahora sincroniza un segundo repositorio para configuraciones 3-2-1 de forma nativa. No necesitas una herramienta de replicación externa para el caso básico.
- **Lista blanca `WEBHOOK_ALLOWED_ORIGINS` (v0.36.0).** ntfy autoalojado, Gotify, webhooks genéricos y URLs personalizadas de Shoutrrr necesitan una lista blanca explícita de orígenes. Slack, Discord, Pushover, Telegram y el ntfy.sh público no.
- **El stack de autenticación maduró.** 2FA (v0.22), SSO con OIDC y organizaciones (v0.30), passkeys (v0.38), claves de API con caducidad (v0.40) y la opción de desactivar el inicio de sesión con contraseña para despliegues solo-SSO (v0.40).
- **La imagen se hizo más pequeña y la app más rápida.** De 597 MB a 245 MB a partir de v0.27.0, que es también cuando la app migró a TanStack Start.
- **Existen agentes remotos, pero solo en alfa.** Los binarios `zerobyte-agent` se publicaron en v0.44.0-alpha.x (2026-10). Alfa, sin soporte oficial, no para producción. Lo mismo aplica a las apps de escritorio.
Una nota sobre las capturas de pantalla de abajo: provienen de la interfaz de diciembre de 2025. La interfaz de v0.43 añadió una barra lateral nueva y una página de Actividad. Los flujos de trabajo son los mismos; la decoración alrededor no.
## Requisitos previos
- Un VPS Linux o máquina de homelab con Docker y Docker Compose instalados
- **Docker con root.** Docker rootless no puede realizar los montajes de kernel que Zerobyte usa para los volúmenes NFS/SMB/WebDAV
- 2 GB de RAM es cómodo; la guía oficial de ajuste de rendimiento muestra que también corre en máquinas de baja potencia con ajustes de `GOMAXPROCS`
- Disco local para `/var/lib/zerobyte` (base de datos SQLite + claves). Evita recursos compartidos de red aquí
- Opcional: rclone en el host si quieres repositorios basados en rclone (el binario de rclone viene dentro de la imagen; la instalación en el host solo sirve para crear la configuración)
- Un dominio y un proxy inverso si quieres HTTPS, que es lo que quieres
- En TrueNAS: `/var/lib` es efímero. Apunta `/var/lib/zerobyte` a un dataset dedicado o las actualizaciones se comerán tu base de datos
Verifica que Docker esté sano antes que nada:
```bash
docker info >/dev/null && echo "rootful docker OK"
```
Si eso falla sin `sudo`, tu demonio no está corriendo o tu usuario no está en el grupo `docker`. Arréglalo primero.
_Los precios de los VPS subieron en todos los proveedores en 2026. Si estás replanteándote un servidor alquilado, mira [qué cambió y cuándo gana un mini PC](/es/subidas-precios-vps/). Si un mini PC gana para tu homelab, el [mini PC ASUS DC510](https://go.bitdoze.com/asus-dc510) es la clase de máquina que elegiría como destino local y silencioso para copias de seguridad._
Panorama de costes: Zerobyte en sí es gratis (AGPL-3.0). Pagas la máquina (aproximadamente la clase de VPS de 5 a 10 $/mes, o la compra de un mini PC) y el backend de almacenamiento al que apuntes los repositorios. La sección de repositorios cubre cómo mantener predecible la factura de almacenamiento.
## Instala Zerobyte con Dokploy
Dokploy es mi opción por defecto para apps de Docker que necesitan un dominio y TLS sin escribir etiquetas de Traefik a mano. Si aún no lo tienes, sigue primero [cómo instalar Dokploy](/dokploy-install/).
### Paso 1: crea el servicio
1. Abre tu proyecto de Dokploy
2. Haz clic en Add Service y elige Compose
3. Nómbralo `zerobyte`
Si los servicios Compose son nuevos para ti, consulta [cómo desplegar una app de Docker Compose en Dokploy](/dokploy-docker-compose-app/) para ver el recorrido completo de esa pantalla.
### Paso 2: pega el archivo compose
Genera primero el secreto de la app y guarda la salida en un lugar seguro fuera de este servidor:
```bash
openssl rand -hex 32
```
Luego pega esto en el servicio:
```yaml
services:
zerobyte:
image: ghcr.io/nicotsx/zerobyte:v0.43
networks:
- dokploy-network
restart: unless-stopped
cap_add:
- SYS_ADMIN
devices:
- /dev/fuse:/dev/fuse
environment:
- TZ=UTC
# required since v0.24; must match the URL you open in the browser. https:// enables Secure cookies
- BASE_URL=https://zerobyte.example.com
# required since v0.23; encrypts secrets stored in the DB. Use the openssl output from above
- APP_SECRET=
# v0.32.1+; makes rate limiting key off X-Forwarded-For behind your proxy
- TRUST_PROXY=true
volumes:
- /etc/localtime:/etc/localtime:ro
# keep this bind mount on local disk so you can back it up as a plain directory
- /var/lib/zerobyte:/var/lib/zerobyte
# sample local repository path, change to your storage
- /srv/backups:/backups
# sample source data to back up, read-only
- /srv/data:/data:ro
# optional, delete if you do not use rclone remotes
- /etc/rclone:/root/.config/rclone:ro
networks:
dokploy-network:
external: true
```
Algunas notas sobre este archivo compose:
- No hay bloque `ports:` a propósito. El contenedor permanece en `dokploy-network` y Traefik llega a él. No publiques `4096` en el host en la ruta con Dokploy.
- `/srv/backups` es una ruta de ejemplo para el repositorio local. Cámbiala por tu ubicación de almacenamiento.
- `/srv/data` son los datos de origen a respaldar. Monta los orígenes en solo lectura cuando sea posible.
- `/etc/rclone` es opcional. Quítalo si no usas remotos de rclone.
- La interfaz escucha en el puerto `4096` dentro del contenedor.
### Paso 3: dominio y puerto
Crea un dominio en Dokploy y mapea al puerto `4096`. Tras el despliegue, abre `https://zerobyte.example.com` (lo que hayas puesto en `BASE_URL`) para llegar a la interfaz.
Las cookies Secure solo se activan cuando `BASE_URL` empieza con `https://`. Si sirves la interfaz en más de un hostname, lista los extras en `TRUSTED_ORIGINS`. Si la URL que escribes en el navegador no coincide con `BASE_URL`, espera rarezas con el inicio de sesión y los callbacks.
Mantén `/var/lib/zerobyte` en disco local. Apuntarlo a un recurso compartido de red suele causar problemas de permisos y bajo rendimiento.
**Verificación**
```bash
curl -sI https://zerobyte.example.com | head -5
```
Quieres `HTTP/2 200` o `302` más las cabeceras TLS. En el navegador deberías caer en la configuración inicial, y la app debería obligarte a descargar la clave de recuperación antes de dejarte hacer cualquier otra cosa. Ese comportamiento es el correcto. Lee la [sección de la clave de recuperación](#la-clave-de-recuperación-y-app_secret-tus-claves-reales) antes de hacer clic para continuar.
**Modos de fallo**
- El contenedor reinicia en bucle: faltan `APP_SECRET` o `BASE_URL`. Revisa `docker logs zerobyte`.
- 502 desde Traefik: el dominio no está asociado al servicio, o está mapeado a un puerto distinto de `4096`.
- Bucle de cookies/inicio de sesión tras poner la app detrás de un proxy: `BASE_URL` no coincide con la URL pública, o el proxy no está pasando `X-Forwarded-Proto`.
## Instala Zerobyte con Docker Compose
Ruta independiente, sin PaaS. Úsala si ejecutas Docker puro en un VPS o un NAS. El README sigue planteando la misma disyuntiva de antes: un archivo compose con privilegios para montajes de red dentro del contenedor, y otro sin ellos.
Ambas variantes de abajo fijan `ghcr.io/nicotsx/zerobyte:v0.43` y establecen `BASE_URL` + `APP_SECRET`. Genera primero el secreto (`openssl rand -hex 32`).
Usa esta si quieres que Zerobyte monte recursos NFS, SMB, WebDAV o SFTP dentro del contenedor. `cap_add: SYS_ADMIN` hace el trabajo pesado; `/dev/fuse` es necesario para montajes basados en FUSE (rclone mount, sshfs). No hace falta para CIFS.
```yaml
services:
zerobyte:
image: ghcr.io/nicotsx/zerobyte:v0.43
container_name: zerobyte
restart: unless-stopped
cap_add:
- SYS_ADMIN
devices:
- /dev/fuse:/dev/fuse
ports:
# loopback bind by default; see the note below
- "127.0.0.1:4096:4096"
environment:
- TZ=UTC
# required since v0.24. Change when you put a real domain on it
- BASE_URL=http://127.0.0.1:4096
# required since v0.23
- APP_SECRET=
# set true only behind a reverse proxy you control
- TRUST_PROXY=false
volumes:
- /etc/localtime:/etc/localtime:ro
- /var/lib/zerobyte:/var/lib/zerobyte
- /srv/backups:/backups
- /srv/data:/data:ro
- /etc/rclone:/root/.config/rclone:ro
```
Si solo respaldas directorios locales, quita la capability y el dispositivo FUSE. Todos los tipos de repositorio siguen funcionando en esta variante. Lo único que pierdes es montar NFS/SMB/WebDAV/SFTP desde dentro del contenedor.
```yaml
services:
zerobyte:
image: ghcr.io/nicotsx/zerobyte:v0.43
container_name: zerobyte
restart: unless-stopped
ports:
- "127.0.0.1:4096:4096"
environment:
- TZ=UTC
- BASE_URL=http://127.0.0.1:4096
- APP_SECRET=
volumes:
- /etc/localtime:/etc/localtime:ro
- /var/lib/zerobyte:/var/lib/zerobyte
- /srv/data:/data:ro
```
**Contrapartidas**
- Menor radio de impacto, menos privilegios
- Perfectamente válido para directorios locales y todos los backends de repositorio
- Sin montajes NFS, SMB, WebDAV ni SFTP dentro del contenedor (móntalos en el host y pasa la ruta con un bind)
Inícialo:
```bash
docker compose up -d
docker logs -f zerobyte
```
**Verificación**
Los registros muestran un arranque limpio, y `curl -sI http://127.0.0.1:4096` devuelve `200`. Como hicimos bind a loopback, accede a la interfaz con un túnel SSH desde tu equipo:
```bash
ssh -L 4096:localhost:4096 user@your-server
# then open http://127.0.0.1:4096
```
Hacer bind de `127.0.0.1:4096:4096` en lugar de `4096:4096` es deliberado. Los puertos publicados del contenedor ignoran las reglas de UFW en el host Docker. Si de verdad quieres acceso LAN en `4096:4096`, lee primero [por qué los puertos publicados de Docker se saltan tus reglas de firewall](/docker-bypasses-firewall/).
**Modos de fallo**
- Puerto 4096 ya en uso: `ss -tlnp | grep 4096` y mueve el lado del host (`"4097:4096"`).
- Contenedores huérfanos tras un renombrado: `docker compose ls` muestra el nombre del proyecto. Experimentos viejos con otro nombre de proyecto pueden retener el puerto o la ruta del bind.
- Bucle de reinicios: el mismo problema de variables ausentes que en la ruta con Dokploy. `docker logs zerobyte` dice qué variable es.
## Añade tu primer volumen
Zerobyte respalda datos desde volúmenes, las ubicaciones de origen que montas en el contenedor. Para respaldar un directorio local, haz bind en el archivo compose y luego elígelo en la interfaz.
Ejemplo de ruta en el host:
```diff
services:
zerobyte:
volumes:
- /var/lib/zerobyte:/var/lib/zerobyte
+ - /srv/projects:/projects:ro
```
Luego ve a Volumes en Zerobyte y crea un nuevo volumen «Directory» que apunte a `/projects`.
Los tipos de volumen soportados ahora incluyen directorios locales, NFS, SMB, WebDAV y **SFTP** (añadido en v0.21). Los tipos de volumen remotos necesitan la variante completa del compose con `SYS_ADMIN`. Los volúmenes estilo FUSE usan por defecto el comportamiento `--ignore-inode` de Restic (desde v0.36.0), que es lo que quieres en sistemas de archivos de red donde los números de inodo mienten.
Los volúmenes tienen chequeos de salud y remontaje automático. Si un recurso compartido cae durante la noche, Zerobyte reintenta en lugar de fallar el trabajo una vez y quedarse callado.
**Verificación:** el volumen aparece como saludable en la interfaz y el selector de archivos lista archivos reales de él. Si el selector está vacío, la ruta del bind dentro del contenedor es incorrecta.
## Crea un repositorio
Los repositorios son donde viven tus snapshots cifrados. Aquí es donde más cambió el modelo mental desde 2025.
Los repositorios creados en la interfaz los inicializa Zerobyte con una contraseña de Restic a nivel de organización. Descargas esa contraseña una vez como clave de recuperación (`restic.pass`). Las contraseñas de repositorio personalizadas solo existen para repositorios importados o externos. Detalles en la [sección de la clave de recuperación](#la-clave-de-recuperación-y-app_secret-tus-claves-reales).
| Tipo de repositorio | Ejemplos |
| --- | --- |
| Directorio local | `/var/lib/zerobyte/repositories/myrepo`, o una ruta con bind como `/backups` |
| Compatible con S3 | AWS S3, MinIO, Wasabi, Backblaze B2, Cloudflare R2 |
| Google Cloud Storage | Buckets de GCS |
| Azure Blob Storage | Contenedores de Azure |
| Remotos de rclone | Google Drive, Dropbox, OneDrive y amigos |
Si eliges un backend puramente por coste para un repositorio de copias, compara [el almacenamiento compatible con S3 más barato para repositorios de copias de seguridad](/es/bunny-storage-vs-s3-vs-backblaze/) antes de comprometerte. El almacenamiento es barato; el egress en la restauración es donde aparece la factura.
Opciones por repositorio que conviene conocer:
- **Límites de ancho de banda** (v0.23) para que una primera copia no sature el uplink de un VPS barato
- **Modo de compresión** `off` / `auto` / `max`, anulable por trabajo desde v0.42
- **Repositorios editables** (v0.28.1) en lugar de borrar y recrear
- **TLS inseguro / CA personalizada** por repositorio (v0.21) para MinIO con certificados internos
- **Desactivar los chequeos de salud automáticos por repositorio** (v0.43) si un backend es lento y ruidoso
**Verificación:** el repositorio aparece como inicializado y una lista de snapshots vacía pero válida se abre sin errores. Un repositorio no inicializado rechazará la primera copia con un error de contraseña o de backend.
**Nota de costes:** almacenamiento más egress es el coste real, no el software. Los límites de ancho de banda evitan que una primera sincronización devore un enlace medido. Planifica la ruta de restauración antes que la de copia.
### Usa rclone para almacenamiento en la nube
1. Instala rclone en tu host: `curl https://rclone.org/install.sh | sudo bash`
2. Configura un remoto: `rclone config`
3. Monta la configuración en el contenedor:
```diff
services:
zerobyte:
volumes:
- /var/lib/zerobyte:/var/lib/zerobyte
+ - ~/.config/rclone:/root/.config/rclone:ro
```
Si ejecutas el contenedor como usuario no-root, define `RCLONE_CONFIG_DIR` apuntando a donde lo montaste. «No remotes available» en la interfaz casi siempre significa que la configuración cayó en la ruta equivocada.
Tras reiniciar el contenedor, elige rclone como tipo de repositorio y selecciona tu remoto.
**Verifica antes de confiar:** ejecuta `rclone listremotes`, `rclone ls remote:` y un `rclone mount` de prueba **en el host**. Si el remoto se comporta mal fuera de Zerobyte, también lo hará dentro. Depurar en el host siempre es más rápido que depurar a través de la interfaz.
## La clave de recuperación y APP_SECRET: tus claves reales
Esta es la sección que decide si tus copias de seguridad serán recuperables dentro de seis meses. Dos secretos distintos, dos trabajos distintos.
**`APP_SECRET`** cifra las credenciales y secretos guardados en la base de datos de Zerobyte (contraseñas de repositorio, tokens de notificación). Genéralo tú mismo (`openssl rand -hex 32`) y pásalo con la variable `APP_SECRET`, o con `APP_SECRET_FILE` (v0.34.0) si usas Docker secrets. Desde v0.37.3, los valores cifrados con un `APP_SECRET` distinto se rechazan de plano, así que este valor es crítico para actualizaciones y migraciones. Piérdelo y las credenciales guardadas se vuelven ilegibles.
**La clave de recuperación, `restic.pass`**, es la contraseña del repositorio Restic. Para los repositorios creados en la interfaz es la predeterminada a nivel de organización. La configuración inicial fuerza una redirección a `/download-recovery-key` hasta que un propietario o administrador la descarga, reintroduciendo la contraseña. Ese flujo molesto es justamente el punto. Es la única copia de la contraseña que desbloquea todos los repositorios que Zerobyte inicializó.
Guarda ambos fuera del servidor antes de programar nada. Un gestor de contraseñas más una copia impresa u offline es suficiente. Si el servidor arde y ambas claves solo estaban en el servidor, las copias de seguridad son ruido cifrado. La documentación es tajante con esto por una razón.
v0.43.0 añadió exportación/importación cifrada de la configuración como archivo `.zbex` protegido con contraseña para migrar instancias, y la interfaz te recuerda reexportar la clave de recuperación si tiene más de un año. Úsalo cuando cambies de máquina, y guarda la exportación con el mismo cuidado que la propia clave.
Lista de custodia de claves:
- Descarga `restic.pass` durante la configuración inicial (solo propietario/admin, con reintroducción de contraseña)
- Guarda `restic.pass` fuera del servidor: gestor de contraseñas más una copia offline
- Anota `APP_SECRET` en el mismo gestor en el momento en que lo generes
- Haz una prueba de desbloqueo con la CLI (fragmento abajo) para saber que la clave funciona
- Reexporta la clave de recuperación si la interfaz te avisa de que está obsoleta
**Vuélvete a entrar.** Si un administrador queda fuera, la CLI incluida restablece las credenciales desde el contenedor:
```bash
docker exec -it zerobyte bun run cli reset-password --username admin
# also available: disable-2fa, change-username, change-email, rekey-2fa, assign-organization
# passwords must be 8-128 characters
```
**Verificación:** con `restic.pass` guardado en `/secure/restic.pass`, ejecuta el fragmento de la CLI en la [sección de la CLI de Restic](#la-cli-de-restic-contra-los-repositorios-de-zerobyte). `restic snapshots` debería listar lo mismo que muestra la interfaz. Eso prueba que la clave que descargaste es la real.
**Modos de fallo**
- Atascado en la pantalla de descarga: es por diseño. Descarga la clave y la redirección termina.
- La CLI dice «wrong password»: estás usando una contraseña que inventaste en lugar de `restic.pass`. Para los repositorios creados en la interfaz solo hay una contraseña correcta, y es la clave de recuperación.
## Crea tu primer trabajo de copia de seguridad
El camino feliz, una vez que existen volúmenes y repositorios:
1. Elige un volumen de origen y un repositorio
2. Define una programación (diaria, semanal o cron personalizado)
3. Añade rutas a incluir y excluir
4. Configura la retención (keep daily, weekly, monthly, yearly)
5. Ejecuta el trabajo una vez manualmente para verificar credenciales y rendimiento antes de que dispare la programación
Cosas que la interfaz puede hacer ahora y no podía en 2025:
- **Backup now** bajo demanda sin crear una entrada cron falsa (v0.33)
- **Reintentos automáticos** con cantidad y retardo configurables (v0.34)
- **Las copias programadas interrumpidas se reencolan** tras un reinicio en lugar de saltarse en silencio (v0.41)
- **Flags personalizados de Restic por trabajo**: `--read-concurrency`, `--exclude-larger-than`, `--no-scan`, `--pack-size`
- **Anulación de compresión por trabajo** (v0.42), así un mismo repositorio puede servir tanto archivos fríos como datos calientes
**Verificación:** ejecuta el trabajo manualmente, confirma que aparece un snapshot en la lista y lee el registro del trabajo de principio a fin. Una insignia verde con un registro vacío está bien. Una insignia verde con reintentos al inicio del registro merece ser comprendida antes de confiar en la programación.
**Nota operativa:** programa la primera ejecución en una ventana de poco tráfico. La primera copia es intensiva en E/S y ancho de banda; las incrementales no.
## Repositorios espejo para copias de seguridad 3-2-1
Un espejo es un segundo repositorio Restic que Zerobyte mantiene sincronizado con tu principal. Esto cierra el agujero de «pero mis copias viven en el mismo NAS que los datos».
Flujo de trabajo en la interfaz:
1. Crea un segundo repositorio en otro proveedor o sitio (este es el destino del espejo).
2. Vincúlalo al primario como espejo.
3. Rellena los snapshots existentes. La interfaz de relleno existe desde v0.35.0; desde v0.43.0 puedes elegir por espejo los snapshots que faltan y sincronizar exactamente esos.
4. Observa el progreso y cancela si hace falta (progreso en vivo desde v0.42.0). Los fallos de sincronización del espejo envían notificaciones desde v0.43.2, que es lo que quieres.
Descripción oficial del patrón: [estrategia de copias 3-2-1](https://zerobyte.app/docs/guides/3-2-1-backup-strategy).
Los espejos protegen contra la pérdida de un backend de repositorio. No protegen contra un host comprometido que tiene ambas claves. Para eso están el almacenamiento de `restic.pass` fuera del servidor y la copia offline.
Y no olvides la propia instancia. La base de datos de Zerobyte es pequeña pero crítica. [Respalda tus metadatos de Dokploy en Cloudflare R2](/dokploy-backups-cloudflare-r2/) si Dokploy ejecuta la app, y trata `/var/lib/zerobyte` de la misma manera. R2 (o cualquier destino S3 barato) sirve perfectamente como destino del espejo.
**Nota de costes:** un espejo aproximadamente duplica el gasto en almacenamiento. Elige un segundo backend deliberadamente aburrido, no una segunda copia en la misma cuenta y región.
## Restaura datos
Abre Backups, selecciona un snapshot y restaura los archivos a sus rutas originales. Para restauraciones parciales, elige solo los archivos que necesitas y Zerobyte los extrae de Restic.
Novedades desde la primera guía:
- **Descargas de snapshots desde el navegador** (v0.29): un snapshot completo se descarga como `.tar`, un archivo suelto se descarga en bruto. Útil cuando solo necesitas recuperar una configuración y no quieres lanzar un trabajo de restauración.
- **Restauraciones cancelables** (v0.41): detén una restauración desbocada en lugar de esperar a que termine.
- **Restauración en una ubicación personalizada**, incluido un directorio temporal para verificación.
- Las restauraciones desde volúmenes de solo lectura no pueden apuntar a la ubicación original (v0.42). Restaura en algún lugar con escritura.
**Verificación:** restaura un conjunto pequeño de archivos en un directorio temporal y haz diff contra el origen antes de confiar en la tubería.
```bash
diff -r /srv/data/sample /tmp/restore-test/sample && echo "restore verified"
```
Hazlo una vez al desplegar y una vez cada pocos meses. Es la única prueba que importa.
## Notificaciones
Los fallos silenciosos de copias son el modo de fallo por defecto de toda herramienta de backup. No vivas con ellos.
Los destinos incluyen Slack, Discord, Pushover, Telegram, Gotify, ntfy (autenticación con access token desde v0.21), webhooks genéricos (v0.21) y URLs personalizadas de Shoutrrr. Desde v0.36.0 también hay webhooks previos y posteriores a la copia si quieres poner en pausa una app o lanzar un trabajo en otra máquina.
Cada canal de notificación muestra **el estado de salud y el último error de entrega** (v0.36.0). Úsalo. Un canal que falló hace tres días es exactamente el que no te avisará de la copia fallida de mañana.
Desde v0.36.0, los webhooks salientes, Gotify, ntfy autoalojado y las URLs personalizadas de Shoutrrr requieren `WEBHOOK_ALLOWED_ORIGINS`, una coincidencia exacta de origen de esquema + host + puerto (las rutas se ignoran). Si tu ntfy autoalojado dejó de entregar en silencio tras actualizar más allá de v0.36, esta es la razón. El ntfy.sh público y los proveedores fijos (Slack, Discord, Pushover, Telegram) no lo necesitan. Los webhooks de copia no siguen redirecciones.
**Verificación:** envía una notificación de prueba y confirma que el estado de salud muestra una marca de tiempo de última entrega reciente. Para una cobertura real de la propia máquina, combina esto con [monitorización de servidor con Beszel y Uptime Kuma](/beszel-uptime-kuma/) para que la máquina apagándose también sea un evento, no un misterio.
## Mantén Zerobyte fuera de internet abierta
El README es directo: ejecutar Zerobyte expuesto a internet está «altamente desaconsejado». Estoy de acuerdo. Esta app guarda las llaves de todas las copias de seguridad que tienes.
v0.19.0 (2025-12-17) corrigió una vulneración de autenticación que afectaba a todas las versiones anteriores: los endpoints de la API eran accesibles sin sesión. Fija una versión actual y actualiza con prontitud. Ejecutar etiquetas antiguas de un plano de control de copias es cómo conviertes un fallo de disco en un incidente de seguridad.
Escalera de exposición, de mejor a peor:
1. Solo red privada. Pon Zerobyte en Tailscale o WireGuard y nunca publiques el puerto 4096. Zerobyte incluye una [guía oficial de Tailscale](https://zerobyte.app/docs/guides/tailscale); si prefieres autoalojar el plano de control, mira [autoalojar un servidor de control de Tailscale con Headscale](/es/headscale-tailscale-autoalojado/)
2. Proxy inverso con TLS, más autenticación a nivel de app. El proxy debe pasar `X-Forwarded-Proto`; usa `TRUSTED_ORIGINS` para hostnames adicionales. v0.43.1 corrigió el inicio de sesión SSO detrás de proxies HTTPS-a-HTTP, así que mantén la imagen al día si usas esa forma. Guía: [proxy inverso](https://zerobyte.app/docs/guides/reverse-proxy)
3. Si publicas un puerto, haz bind a loopback: `127.0.0.1:4096:4096`, y luego entra por túnel o proxy. Nunca `0.0.0.0:4096`. Recuerda que los puertos publicados del contenedor se saltan UFW, consulta [por qué Docker se salta tu firewall (y la solución)](/docker-bypasses-firewall/)
4. Refuerza la máquina igualmente: [cómo protegí mi servidor Docker](/es/informe-seguridad-bsi-docker-ufw/)
Stack de autenticación que conviene activar:
- **2FA** (v0.22) para cada cuenta humana
- **Passkeys** (v0.38). Requieren HTTPS o localhost, igual que cualquier otra implementación de WebAuthn
- **SSO con OIDC** con organizaciones e invitaciones (v0.30). El inicio de sesión con contraseña puede desactivarse por completo para despliegues solo-SSO (v0.40)
- **Claves de API con caducidad** (v0.40) en lugar de tokens de larga duración
Limitación honesta: no hay RBAC granular. Los miembros de la organización son operadores de confianza. Invita en consecuencia.
**Nota operativa:** define `TRUST_PROXY=true` solo detrás de un proxy que controlas. Hace que el rate limiting confíe en `X-Forwarded-For`, lo cual solo es seguro cuando controlas el camino de esa cabecera.
## Cómo actualizar Zerobyte de forma segura
Las actualizaciones en la línea 0.x han requerido acción manual al menos una vez. Trátalas como actualizaciones de base de datos, no como `docker compose pull` y a rezar.
1. **Fija la etiqueta menor.** `ghcr.io/nicotsx/zerobyte:v0.43` es una etiqueta menor móvil que sigue el último parche `v0.43.x`. `v0.43.2` es el parche exacto. Fijar la menor es lo que uso por defecto; fija el parche si necesitas repetibilidad byte a byte.
2. **Lee primero las notas de la versión.** El registro de cambios disruptivos hasta ahora: v0.23 (`APP_SECRET` obligatorio), v0.24 (`BASE_URL` obligatorio), v0.32 (eliminadas las referencias dinámicas a secretos `env://` y `file://`, sustituidas por `PROVISIONING_PATH`), v0.36 (`WEBHOOK_ALLOWED_ORIGINS` para endpoints de notificación autoalojados).
3. **Respalda `/var/lib/zerobyte` antes de actualizar.** Es la base de datos SQLite más el material de claves. Un simple `tar` del directorio es suficiente:
```bash
tar -C /var/lib -czf /srv/backups/zerobyte-$(date +%F).tar.gz zerobyte
```
4. **Confirma que `APP_SECRET` y `restic.pass` están guardados fuera del servidor.** Los necesitarás si la máquina muere a mitad de la actualización.
5. Descarga y recrea:
```bash
docker compose pull zerobyte
docker compose up -d
docker logs -f zerobyte
```
Si ejecutas Zerobyte como un stack Compose de Dokploy, el flujo de trabajo es [actualizar stacks de Docker Compose en Dokploy](/dokploy-update-docker-compose/). Y si aún no guardas [copias externas de los datos de la instancia](/dokploy-backups-cloudflare-r2/), la sección de actualización es un buen momento para empezar.
**Rollback:** restaurar la etiqueta de imagen anterior junto con la copia previa a la actualización de `/var/lib/zerobyte` es el camino de deshacer. Las restauraciones probadas vencen a las actualizaciones optimistas; haz el tarball.
**Verificación tras actualizar:** `docker logs zerobyte` está limpio, la interfaz carga y un trabajo corre en verde de principio a fin.
## Solución de problemas de Zerobyte
Escala en este orden, de menor a mayor privilegio:
1. Mejor opción: monta el recurso en el host (unidad systemd o autofs) y haz bind del punto de montaje en el contenedor como un directorio normal. Sin capabilities extra.
2. `cap_add: SYS_ADMIN`. Añade `/dev/fuse` solo para montajes basados en FUSE (rclone mount, sshfs). CIFS no lo necesita.
3. Hosts con AppArmor (Ubuntu/Debian): ejecuta `docker inspect --format '{{.AppArmorProfile}}' zerobyte`. Si imprime `docker-default`, añade `security_opt: ["apparmor:unconfined"]`.
4. Entornos con seccomp restringido: `security_opt: ["seccomp:unconfined"]`. Último recurso, amplía la superficie de ataque.
5. Hosts con SELinux (CentOS/Fedora): `security_opt: ["label:disable"]`.
Prueba el remoto primero en el host: `rclone listremotes`, `rclone ls remote:`, `rclone mount`. Si falla ahí, Zerobyte no es el problema.
«No remotes available» en la interfaz significa que el archivo de configuración está montado en la ruta equivocada. La imagen espera `/root/.config/rclone`. Si ejecutas como no-root, define `RCLONE_CONFIG_DIR` a la ruta donde lo montaste.
Casi siempre es un `APP_SECRET` o `BASE_URL` ausente en v0.23+. `docker logs zerobyte` nombra la variable. Añádela, `docker compose up -d` otra vez.
Desde v0.38.0 los bloqueos obsoletos se eliminan automáticamente y el trabajo reintenta. Hay un botón Unlock manual en la interfaz desde v0.27.0. Usa primero la interfaz; recurre a `restic unlock` por la CLI solo si la interfaz no puede limpiarlo.
Revisa primero `WEBHOOK_ALLOWED_ORIGINS` (ver la sección de Notificaciones). Luego lee el estado de salud del canal para ver el último error de entrega. Los webhooks de copia no siguen redirecciones, así que un 302 de tu endpoint es un fallo silencioso.
## La CLI de Restic contra los repositorios de Zerobyte
Puedes seguir usando el `restic` estándar contra cualquier cosa que gestione Zerobyte. El modelo mental cambió, eso sí: Zerobyte inicializa él mismo los repositorios creados en la interfaz, así que ya no inventas una contraseña y ejecutas `restic init`.
Para leer un repositorio de Zerobyte desde la CLI, usa la clave de recuperación descargada:
```bash
export RESTIC_REPOSITORY=/srv/backups/restic-repo
export RESTIC_PASSWORD_FILE=/secure/restic.pass # downloaded from the Zerobyte UI
restic snapshots
restic check
```
Para los repositorios creados en la interfaz, el único `RESTIC_PASSWORD` correcto es el que hay dentro de `restic.pass`. Las contraseñas de repositorio personalizadas solo existen para repositorios importados o externos. Si la CLI dice «wrong password», estás usando la fuente de clave equivocada, no es un error de tecleo.
Como referencia, esto es lo que la política de retención de la interfaz ejecuta internamente. No lo ejecutes contra repositorios gestionados por Zerobyte salvo que sepas que quieres podar fuera de la app:
```bash
restic -r $RESTIC_REPOSITORY forget --prune \
--keep-daily 7 --keep-weekly 4 --keep-monthly 12 --keep-yearly 3
```
**Verificación:** `restic snapshots` lista los mismos snapshots que muestra la interfaz. Cualquier diferencia significa que apuntas a la ruta de repositorio equivocada o a la clave equivocada.
## Preguntas frecuentes
Solo si quieres que Zerobyte monte recursos NFS, SMB, WebDAV o SFTP dentro del contenedor. Para carpetas locales, usa la variante simplificada del compose sin la capability ni el dispositivo. Todos los backends de repositorio funcionan de ambas formas.
Los repositorios locales viven bajo `/var/lib/zerobyte/repositories` por defecto, salvo que hagas bind de otra ruta como `/backups` y la uses. Los repositorios en la nube se almacenan en el backend que configures. El directorio `/var/lib/zerobyte` también contiene la base de datos SQLite y el material de claves, razón por la cual se queda en disco local y se respalda antes de las actualizaciones.
En el archivo `restic.pass` que descargaste durante la configuración inicial. Esa es la clave de recuperación, y es la contraseña del repositorio para cada repo que Zerobyte inicializó. `APP_SECRET` es un secreto completamente distinto: cifra las credenciales guardadas en la base de datos de Zerobyte. Ambos pertenecen fuera del servidor. Consulta [La clave de recuperación y APP_SECRET](#la-clave-de-recuperación-y-app_secret-tus-claves-reales).
No como función de primera clase hoy. Los agentes remotos (`zerobyte-agent`) se están publicando en la línea alfa v0.44 (binarios linux x64/arm64 y un `Dockerfile.agent`), con enrollment y un servicio systemd en el repo. Alfa, sin soporte oficial, no para producción. Las alternativas prácticas ahora mismo: monta recursos de otras máquinas en la única instancia, o tira de volúmenes SFTP.
No hay un mínimo oficial. 2 GB es cómodo para la interfaz más los trabajos. La guía de ajuste de rendimiento en zerobyte.app documenta los parámetros `GOMAXPROCS` y `RESTIC_PROGRESS_FPS` para máquinas de baja potencia, así que un VPS pequeño o un mini PC es realista. El consumo pesado de recursos es la primera pasada de copia de Restic, no el panel.
Sí. AGPL-3.0, sin nivel de pago anunciado a octubre de 2026. Tus costes reales son la máquina, el backend de almacenamiento, el egress en las restauraciones y el destino del espejo si ejecutas 3-2-1. Los límites de ancho de banda por repositorio evitan que las primeras sincronizaciones devoren un uplink medido.
## Conclusiones
Restic te da copias de seguridad cifradas de confianza. Zerobyte le da a ese motor un plano de control que aún puedes entender a las 2 de la mañana: programaciones, retención, espejos, registros y una ruta de restauración que no empieza con `man restic`. Las versiones de 2026 cerraron la mayoría de las carencias que anoté en la primera versión de esta guía, especialmente los repositorios espejo nativos y un sitio de documentación de verdad.
Si quieres una comparación que valga la pena leer junto a esta, [Pluton: copias de seguridad autoalojadas con Restic y Rclone](/es/pluton-backup-autoalojado/) envuelve el mismo motor Restic y aún gana en amplitud de destinos rclone (más de 80). El viejo encuadre de «Pluton tiene replicación y Zerobyte no» ya no se sostiene: Zerobyte cubre 3-2-1 con repositorios espejo hoy, y los agentes remotos están llegando en alfa. Elige según la interfaz que prefieras y los destinos que uses.
Lista de cierre del operador antes de confiar en este stack:
- Clave de recuperación (`restic.pass`) descargada y guardada fuera del servidor
- `APP_SECRET` anotado en tu gestor de contraseñas
- Una copia manual completada en verde
- Una restauración pequeña validada con `diff` contra el origen
- Prueba de notificación recibida y el estado de salud del canal fresco
- Trabajo programado en una ventana tranquila
- Imagen fijada en `v0.43`
- `/var/lib/zerobyte` respaldado en algún lugar que no sea este disco