Backup per PMI senza spendere 5.000 € l'anno: ho messo su Zerobyte e vi dico come è andata

Parto dal problema. Ho due server: un VPS OVH con Docker (Ghost, Peertube, Umami, Beszel, Caddy) e un server fisico a casa con un disco esterno da 7 TB. Dovevo fare backup dei volumi Docker del VPS sul disco esterno, senza spendere un euro in licenze, e senza che ci volesse un team di tre persone per gestirlo.

Ho guardato le opzioni. Veeam: 5.000 € l'anno per la licenza minima, e parliamo di due server. Proxmox Backup Server: ottimo, ma non uso Proxmox. Bareos: enterprise vero, ma la configurazione è XML su XML e i daemon sono tre per ogni host. UrBackup: semplice, ma niente dedup a livello di blocco e niente offsite nativo.

Poi ho trovato Zerobyte. È un orchestratore di Restic con una web UI, multi-organizzazione, 40+ backend di destinazione (S3, SFTP, rclone, GCS, Azure, e via andando), deduplicazione, crittografia end-to-end, retention GFS, notifiche. Open source, zero licenze. L'ho installato in dieci minuti.

Come è fatto

Zerobyte gira in un container Docker. Sotto il cofano usa Restic come motore di backup. Tu gli dici "fai backup di questo path su questa destinazione, con questa retention, e mandami una mail se fallisce" — e lui lo fa. La web UI ti permette di creare organizzazioni, assegnare volumi, impostare schedule, vedere gli snapshot, e fare restore dal browser.

Nella mia configurazione: Zerobyte gira sul server fisico (MintServer), si connette al VPS via SFTP, e scrive il repo su un disco esterno montato a /media/NAS3/Salvataggio VPS. Tre volumi di backup: i volumi Docker del VPS, i volumi Docker del server locale, e il Caddyfile.

L'installazione

services:
  zerobyte:
    image: ghcr.io/nicotsx/zerobyte:latest
    container_name: zerobyte
    user: "0"
    restart: unless-stopped
    cap_add:
      - SYS_ADMIN
    devices:
      - /dev/fuse:/dev/fuse
    security_opt:
      - apparmor=unconfined
      - seccomp=unconfined
    ports:
      - "4096:4096"   

user: "0" serve perché i file dei database (PostgreSQL, Redis) dentro i volumi Docker sono posseduti da UID diversi e senza root non li leggi. SYS_ADMIN e /dev/fuse sono per il FUSE mount del repo Restic.

Dopo docker compose up -d apri http://localhost:4096, crei l'organizzazione, aggiungi il volume (SFTP verso il VPS), imposti il schedule. Fatto.

I problemi che ho trovato (e come li ho risolti)

Perché non è tutto rose e fiori.

Primo: i symlink. Se dentro i volumi che backuppi ci sono symlink (temi, shortcut, link a cartelle esterne), Restic non riesce a fare readlink e ti sputa un errore a ogni backup. Non è un errore critico — il backup va a buon fine — ma l'email di notifica diventa un muro di JSON. Soluzione: escludili. Nel campo "Exclude patterns" di Zerobyte metti i path dei symlink che ti dà errore.

Secondo: socket, log, cache, dipendenze. *.sock, file .log, node_modules/, cache di package manager, file interni di database (WAL, checkpoint, replication slot). Niente di tutto questo serve in un backup: si rigenera, si ricostruisce, o non è mai stato un dato. Se non li escludi, il repo cresce inutilmente e ti riempie di warning. Esclusioni generiche che funzionano quasi sempre:

*.sock
*.log
node_modules/**
.pnpm-store/**
pg_logical/**   

Attenzione alla sintassi: node_modules/** (con **), non node_modules/. Il primo esclude il contenuto, il secondo no. Mi ci è voluto un po' a capirlo.

Terzo: i permessi. Se i volumi contengono file di database (PostgreSQL, MySQL, Redis) o servizi che girano con UID diversi, l'utente con cui ti connetti via SFTP potrebbe non averci accesso. Il backup va a buon fine ma ti dice "permission denied" su mezza cartella. Soluzione: crea un utente dedicato sul server sorgente con permessi di lettura su tutto (o sudo NOPASSWD), e usa quello come utente SFTP in Zerobyte.

Quarto: la password di Restic. Zerobyte usa una "recovery key" (file restic.pass) che scarichi dalla UI al primo avvio. Tienila al sicuro: senza non puoi leggere il repo. Io l'avevo salvata su un altro PC e ho dovuto recuperarla. Se la perdi, i backup esistono ma non li puoi usare.

Quinto: il cron di notifica. Il backup lo fa Zerobyte (ha il suo scheduler interno). Ma io volevo una mail che mi dicesse "tutto ok" o "qualcosa è andato storto" senza dover controllare l'UI. Ho messo un cron che alle 5:00 controlla l'ultimo snapshot con restic snapshots --latest 1 e mi manda una mail. Se lo snapshot è più vecchio di 12 ore, la mail dice ERRORE. Sembra banale, ma è la cosa che ti fa capire che il backup esiste davvero e non è solo "un processo che gira".

Prima di chiudere: testa il restore

Questa è la cosa che nessuno fa. Il backup gira, le mail dicono "OK", il repo cresce di 38 MB al giorno. Tutto bene. Ma se domani ti serve davvero un file, funziona?

Io non lo sapevo finché non l'ho provato.

In Zerobyte: vai su Backups → scegli lo snapshot di ieri → sfoglia i file → selezionalne uno (un file di config, un database, quello che vuoi) → Restore → scegli una cartella temporanea (non sovrascrivere l'originale).

Ci metti due minuti. Se il file c'è, è leggibile, e il contenuto è quello che ti aspettavi → il backup funziona davvero.

Fallo una volta al mese. Due minuti. È la differenza tra "ho un backup" e "ho un backup che so che funziona".