Backup dei siti su S3 con restic: guida completa per server Linux

26 settembre 2026 · lettura 7 min · Koapanel

Un backup che vive sullo stesso server dei siti sparisce insieme al server. Il modo più solido e economico per proteggere siti e database è inviarli ogni notte, cifrati, su uno storage S3 compatibile con restic, facendo prima un dump coerente dei database, conservando più versioni e provando il ripristino a intervalli regolari. In questa guida trovi tutti i comandi per Ubuntu 24.04; alla fine vediamo come lo stesso lavoro si fa in Koapanel con pochi clic.

Cosa salvare davvero

Su un server di hosting le cose da salvare sono poche ma tutte indispensabili:

• i file dei siti (/var/www), esclusi cache e file temporanei;
• i database, come dump SQL: copiare i file di /var/lib/mysql mentre MariaDB è acceso produce copie spesso inutilizzabili;
• la configurazione: /etc/nginx, /etc/php, /etc/letsencrypt, eventuali cron;
• se hai la posta sul server, anche le caselle.

La regola 3-2-1

La regola classica dice: 3 copie dei dati, su 2 supporti diversi, di cui 1 fuori sede. Tradotta per un VPS:

1. i dati in produzione sul server;
2. un backup su uno storage S3 di un altro fornitore (o almeno di un altro data center);
3. una seconda copia indipendente: un altro bucket, un disco a casa o in ufficio, oppure gli snapshot del provider del VPS.

Gli snapshot del provider da soli non bastano: se perdi l'accesso all'account o il provider ha un problema, spariscono insieme al server.

Scegliere lo storage S3

Qualsiasi servizio compatibile con l'API S3 funziona con restic. Le differenze che contano sono il prezzo per TB, il costo per scaricare i dati (egress) e le regole di conservazione minima.

Prezzi verificati sulle pagine ufficiali a settembre 2026. Due consigli pratici:

• per i dati di clienti europei scegli una regione in UE: semplifica il discorso GDPR;
• con i fornitori che applicano una durata minima, eliminare i backup vecchi prima del termine non fa risparmiare: tienine conto quando imposti la conservazione.

Crea un bucket dedicato e una chiave di accesso limitata a quel bucket, mai la chiave principale dell'account.

Perché restic

restic è un programma di backup libero pensato proprio per questo scenario:

• cifratura sempre attiva: i dati escono dal server già cifrati (AES-256), il provider vede solo blocchi illeggibili;
• deduplica: dopo il primo backup invia solo i blocchi cambiati, quindi i backup giornalieri sono veloci e occupano poco;
• snapshot: ogni backup è una fotografia completa da cui ripristinare file singoli o tutto.

Su Ubuntu 24.04 si installa dai repository (versione 0.16):

sudo apt update
sudo apt install restic
restic version

1. Password e credenziali

Salva le impostazioni in una cartella leggibile solo da root:

sudo mkdir -p /etc/restic
sudo chmod 700 /etc/restic
sudo sh -c 'openssl rand -base64 32 > /etc/restic/password'
sudo chmod 600 /etc/restic/password
sudo nano /etc/restic/env

Contenuto di /etc/restic/env (esempio con Backblaze B2; l'endpoint lo trovi nella pagina del bucket):

RESTIC_REPOSITORY=s3:https://s3.eu-central-003.backblazeb2.com/mio-bucket/server1
RESTIC_PASSWORD_FILE=/etc/restic/password
AWS_ACCESS_KEY_ID=la-tua-key-id
AWS_SECRET_ACCESS_KEY=la-tua-chiave-segreta

sudo chmod 600 /etc/restic/env

Copia la password del repository fuori dal server (in un gestore di password): senza di essa i backup non si possono leggere, da nessuno, nemmeno da te.

Inizializza il repository:

sudo -i
set -a; . /etc/restic/env; set +a
restic init

2. Dump coerenti dei database

Su Ubuntu 24.04 MariaDB 10.11 fornisce mariadb-dump (mysqldump resta come alias). Con tabelle InnoDB, l'opzione --single-transaction produce un dump coerente senza bloccare i siti: tutte le tabelle vengono lette nello stesso istante logico. Con tabelle MyISAM questa garanzia non c'è: convertile in InnoDB oppure accetta un breve blocco con --lock-tables.

Un dump per database è più comodo da ripristinare di un unico file enorme. Lo script completo, da salvare in /usr/local/sbin/backup-siti.sh:

#!/bin/bash
set -euo pipefail
DUMP_DIR=/var/backups/mariadb
mkdir -p "$DUMP_DIR"
chmod 700 "$DUMP_DIR"
rm -f "$DUMP_DIR"/*.sql
# 1. Dump di ogni database (root entra via socket, senza password)
for db in $(mariadb -N -e "SHOW DATABASES" | grep -Ev '^(information_schema|performance_schema|mysql|sys)$'); do
mariadb-dump --single-transaction --quick --routines --triggers --events "$db" > "$DUMP_DIR/$db.sql"
done
# Utenti e permessi
mariadb-dump --system=users > "$DUMP_DIR/_utenti.sql"
# 2. Backup di file, configurazione e dump
restic backup --tag siti --exclude-caches \
--exclude '/var/www/*/tmp' \
--exclude '/var/www/*/public_html/wp-content/cache' \
/var/www /etc/nginx /etc/php /etc/letsencrypt "$DUMP_DIR"
# 3. Conservazione: 7 giornalieri, 4 settimanali, 12 mensili
restic forget --tag siti --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

sudo chmod 700 /usr/local/sbin/backup-siti.sh

I dump non compressi sono voluti: restic comprime e deduplica da solo, mentre un file .gz cambia per intero a ogni esecuzione e annulla la deduplica.

3. Pianificazione con un timer systemd

Un timer systemd è preferibile a cron: registra l'esito nel journal e, con Persistent=true, recupera l'esecuzione persa se il server era spento. Crea /etc/systemd/system/backup-siti.service:

[Unit]
Description=Backup dei siti con restic
Wants=network-online.target
After=network-online.target
[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env
ExecStart=/usr/local/sbin/backup-siti.sh
Nice=19
IOSchedulingClass=idle

e /etc/systemd/system/backup-siti.timer:

[Unit]
Description=Backup notturno dei siti
[Timer]
OnCalendar=*-*-* 03:15:00
RandomizedDelaySec=15m
Persistent=true
[Install]
WantedBy=timers.target

Attiva e prova subito:

sudo systemctl daemon-reload
sudo systemctl enable --now backup-siti.timer
sudo systemctl start backup-siti.service
sudo journalctl -u backup-siti.service -n 50
systemctl list-timers backup-siti.timer

Se preferisci cron, la riga equivalente in /etc/cron.d/backup-siti è:

15 3 * * * root set -a; . /etc/restic/env; set +a; /usr/local/sbin/backup-siti.sh >> /var/log/backup-siti.log 2>&1

4. Controllare il repository

Un repository danneggiato si scopre sempre nel momento peggiore. Una volta a settimana:

restic check
restic check --read-data-subset=5%

Il primo verifica la struttura, il secondo scarica e controlla davvero una parte dei dati (occhio all'egress con i provider che lo fanno pagare).

5. Provare il ripristino

Un backup mai ripristinato è solo una speranza. Almeno una volta al mese ripristina un sito in una cartella di prova, mai sopra quello in produzione:

sudo -i
set -a; . /etc/restic/env; set +a
restic snapshots --tag siti
restic restore latest --tag siti --target /root/prova-ripristino --include /var/www/esempio.it
ls -la /root/prova-ripristino/var/www/esempio.it

E un database in un database di prova:

mariadb -e "CREATE DATABASE prova_ripristino"
restic dump --tag siti latest /var/backups/mariadb/negozio.sql | mariadb prova_ripristino
mariadb -e "SELECT COUNT(*) FROM prova_ripristino.wp_posts"
mariadb -e "DROP DATABASE prova_ripristino"

Annota quanto tempo ci hai messo: è il tuo tempo di ripristino reale, quello da comunicare ai clienti.

6. Proteggere i backup da chi attacca il server

Se un attaccante diventa root sul server, trova le credenziali S3 e può cancellare anche i backup. Per ridurre il rischio:

• usa una chiave limitata al solo bucket dei backup;
• attiva il versioning del bucket con una regola che elimina le versioni vecchie dopo qualche settimana: gli oggetti cancellati restano recuperabili per quel periodo;
• tieni la seconda copia della regola 3-2-1 con credenziali diverse, che il server non conosce, per esempio un altro server che scarica o replica il bucket.

Backup in Koapanel

Tutto quello che hai letto è ciò che Koapanel fa dalla pagina Backup, senza script. Secondo il manuale:

• usa restic e salva i file del sito e i database associati, in forma cifrata;
• la destinazione può essere uno storage S3 compatibile (Amazon S3, Wasabi, Backblaze B2, MinIO…), la scelta consigliata, oppure una cartella locale, meglio se su un altro disco: dalla pagina Dischi puoi preparare un disco nuovo e montarlo per esempio in /mnt/backup;
• al primo salvataggio genera la password del repository e te la mostra: va conservata lontano dal server;
• il backup automatico giornaliero parte all'orario che scegli, con la conservazione di giornalieri, settimanali e mensili; i più vecchi si eliminano da soli;
• puoi lanciare subito Backup di tutti i siti ora o il backup di un solo sito dalla sua scheda;
• se un backup non riesce, gli amministratori ricevono un'email;
• il ripristino si fa dalla scheda Backup del sito: scegli la copia per data e ripristini file, database o entrambi;
• le chiavi S3 sono salvate cifrate sul server.

Anche gli utenti e i rivenditori vedono e ripristinano i backup dei propri siti, senza accesso al resto del server.

Cosa resta a te: la seconda copia della regola 3-2-1 (per esempio la replica del bucket presso il provider) e le prove di ripristino: il manuale non prevede prove automatiche, quindi ogni tanto ripristina un sito di test creato apposta e controlla che funzioni. Il ripristino sovrascrive file e database attuali: se non sei sicuro, fai prima un backup dello stato attuale.

Il backup è incluso in tutti i piani, anche quello gratuito: vedi i prezzi.

Domande frequenti

Ogni quanto devo fare il backup?

Per la maggior parte dei siti una volta al giorno basta. Per un e-commerce con molti ordini valuta più esecuzioni al giorno, almeno dei database: con restic i backup successivi al primo sono piccoli e veloci.

Posso usare lo stesso bucket per più server?

Sì, ma usa un percorso diverso per ogni server (/server1, /server2) e password diverse. Così un problema su un repository non tocca gli altri.

Quanto spazio occupano i backup?

Molto meno della somma delle copie: grazie a deduplica e compressione, conservare 7 giornalieri, 4 settimanali e 12 mensili occupa di solito poco più della dimensione dei siti più le modifiche nel tempo. Controlla con restic stats.

Cosa succede se perdo la password di restic?

I backup diventano illeggibili per sempre: nessuno può recuperarli, nemmeno il provider. Conservala in almeno due posti fuori dal server.

Posso ripristinare su un altro server?

Sì. Installa restic, copia /etc/restic/env e la password, e usa restic restore. È anche il modo migliore per provare un disaster recovery completo.

Metti al sicuro i tuoi siti stasera

Puoi seguire questa guida a mano, oppure installare Koapanel su un Ubuntu 24.04 nuovo e attivare il backup su S3 in qualche minuto, insieme a firewall, antimalware e isolamento dei siti descritti nella guida sulla sicurezza dei VPS:

curl -fsSL https://get.koapanel.app | sudo bash

Preferisci guardare prima? Prova la demo pubblica oppure leggi la documentazione.