Cosa configurerete
Gli attaccanti che entrano in una rete di solito cercano di cancellare o cifrare i backup prima di cifrare i server. Un backup che un account amministratore rubato può cancellare non basta quindi. Questa guida costruisce con BackupZit una protezione a strati: un backup principale su storage locale, una copia in un altro luogo e uno storage in cui i backup non possono essere distrutti prima della fine di un periodo stabilito, nemmeno con le credenziali dello storage. BackupZit è gratuito e open source (AGPLv3); tutto quanto descritto qui fa parte del prodotto gratuito.
La regola 3-2-1, e 3-2-1-1-0
La regola 3-2-1: 3 copie dei dati, su 2 supporti diversi, 1 delle quali fuori sede. L’estensione 3-2-1-1-0 aggiunge 1 copia immutabile o offline e 0 errori nella verifica dei backup. In BackupZit:
| Parte | In BackupZit |
|---|
| 3 copie | I dati di produzione, un job di backup e un job di copia. |
| 2 supporti | Due destinazioni di storage, ad es. un NAS via SMB o SFTP e un bucket S3. |
| 1 fuori sede | La copia va nel cloud (S3, Azure Blob Storage) o su un repository protetto in un altro edificio. |
| 1 immutabile o offline | S3 con Object Lock, un repository protetto o dischi USB a rotazione. |
| 0 errori | I test di ripristino automatici e la verifica di tutti i dati archiviati, con un avviso quando qualcosa fallisce. |
Serve una console BackupZit con agenti sulle macchine da proteggere; le guide per Proxmox VE, Hyper-V e immagini disco Windows mostrano questi primi passi.
Passo 1 — Storage principale per ripristini veloci
Nella console aprite Archiviazione → Aggiungi destinazione di storage. Per la prima copia scegliete uno storage nella rete locale, così backup e ripristini girano alla massima velocità: una condivisione SMB su un file server o NAS, oppure un server Linux o NAS via SFTP (la sua chiave host viene fissata). Date alla destinazione un account dedicato che possa scrivere solo nella cartella dei backup e non aggiungete lo storage dei backup al dominio Windows.
Al salvataggio la console prova subito la destinazione: una password, una chiave host o una condivisione sbagliata emerge adesso e non al primo backup. Verifica connessione nell’elenco degli storage ripete la prova.
Passo 2 — Aggiungere uno storage immutabile
BackupZit offre due tipi di storage in cui i backup non possono essere cancellati né sovrascritti prima della fine del loro periodo. Idealmente è anche fuori sede, così una sola destinazione copre entrambe le esigenze.
Opzione A: S3 con Object Lock
- Create il bucket con Object Lock attivo — su AWS, Wasabi e Backblaze B2 è un’opzione alla creazione del bucket; su MinIO
mc mb --with-lock.
- Aggiungete una regola di lifecycle che elimini le versioni non correnti dopo un giorno (MinIO:
mc ilm rule add --noncurrent-expire-days 1 --expire-delete-marker). Cancellare un backup bloccato aggiunge solo un delete marker; la regola libera lo spazio quando i blocchi scadono.
- Nella console aggiungete una destinazione di tipo Compatibile S3 (AWS, Wasabi, Backblaze B2, MinIO, …) con endpoint, bucket e una chiave di accesso per quel bucket.
- Spuntate Backup immutabili (S3 Object Lock, modalità compliance) per … giorni (30 predefinito) e scegliete un periodo lungo almeno quanto la conservazione da proteggere.
Ogni file scritto dagli agenti viene allora bloccato in modalità compliance per quel periodo più un giorno: nessuno — né un attaccante con le chiavi né il proprietario del bucket — può cancellarlo o sovrascriverlo prima. I dati che un nuovo backup riutilizza da quelli precedenti ricevono un blocco prolungato, così ogni punto di ripristino resta protetto per l’intero periodo. Su storage immutabile la verifica della connessione si limita ad accedere ed elencare, e controlla che il bucket abbia davvero Object Lock.
Azure e Google Cloud: per Azure Blob Storage attivate in Azure l’immutabilità a livello di versione con un criterio di conservazione basato sul tempo sul container. Google Cloud Storage funziona come destinazione S3, ma senza l’opzione Object Lock; impostate invece in Google Cloud un criterio di conservazione del bucket (e bloccatelo).
Opzione B: repository protetto sul vostro server Linux
Un server Linux dedicato esegue backupzit-repo (i pacchetti deb e rpm sono allegati a ogni release su GitHub):
apt install ./backupzit-repo_*.deb # oppure: dnf install ./backupzit-repo-*.rpm
vi /etc/backupzit-repo/repo.env # BACKUPZIT_REPO_LOCK_DAYS=30
systemctl start backupzit-repo
backupzit-repo add-key office-console # mostra la chiave di accesso una sola volta
backupzit-repo fingerprint # impronta del certificato
Nella console aggiungete una destinazione di tipo Repository protetto (backupzit-repo su Linux, immutabile) con l’indirizzo del server (porta 8500 predefinita), la chiave di accesso e l’impronta.
- Agenti e console possono solo aggiungere file; i file esistenti non vengono mai sovrascritti.
- Ogni file riceve l’attributo immutabile (
chattr +i) per il periodo impostato su quel server, più un giorno. Nemmeno root può cancellarlo senza prima togliere l’attributo.
- Le cancellazioni dai client — per la conservazione o da parte di un attaccante con la chiave di accesso — nascondono soltanto i file fino alla fine del loro periodo.
- Il periodo si imposta solo sul server del repository; console e agenti non possono modificarlo.
Dopo la configurazione disattivate SSH e ogni altro accesso remoto a quel server e proteggete la sua console locale, l’iDRAC/iLO o l’accesso all’hypervisor: la protezione è forte quanto il suo account root.
Passo 3 — Cifratura e chiave di ripristino
Lasciate attivo Cifra i backup (AES-256) (predefinito). Contenuto dei file, nomi, struttura delle cartelle ed elenchi degli snapshot vengono cifrati con AES-256-GCM prima di lasciare l’agente, e ogni modifica ai dati viene rilevata. L’immutabilità impedisce la cancellazione, la cifratura impedisce la lettura: servono entrambe.
Per ogni destinazione cifrata la console mostra una Chiave di ripristino e offre un foglio di ripristino. Conservatelo offline e separato dai backup: con la chiave, la posizione dello storage e le sue credenziali potete ripristinare anche senza la console; senza la chiave nessuno può leggere i backup, nemmeno il supporto di BackupZit.
Passo 4 — Job di backup e conservazione
Create il job in Job di backup con lo storage principale del passo 1. In Conserva backup impostate gli N più recenti più punti di ripristino giornalieri, settimanali e mensili: ad esempio 3 recenti, 7 giornalieri, 4 settimanali e 6 mensili tengono circa sei mesi con una ventina di punti di ripristino. La deduplicazione salva i dati invariati una sola volta.
Obiettivo del punto di ripristino (RPO), ore indica quanto può invecchiare l’ultimo backup riuscito, ad es. 26 per un job giornaliero. Un job che lo manca compare sulla dashboard e viene segnalato, il che intercetta anche un agente offline da giorni o una pianificazione rimossa per errore.
Passo 5 — Copia fuori sede con un job di copia
Create un secondo job e scegliete Copia di backup. In Copia i backup di selezionate il job del passo 4 e come Destinazione di archiviazione la destinazione immutabile o fuori sede del passo 2.
- L’agente del job di origine copia i backup esistenti; la macchina protetta non viene riletta.
- Vengono inviati solo i dati non ancora presenti a destinazione, cifrati di nuovo con la chiave della destinazione.
- Dopo ogni backup del job di origine (predefinito) mantiene la copia aggiornata; va bene anche una pianificazione normale, ad es. una volta per notte con una linea lenta.
- La copia ha la propria conservazione, ad es. 7 giornalieri sul NAS e 12 mensili nel cloud. Ogni punto di ripristino è bloccato per N giorni dalla sua creazione; con un blocco di 30 giorni i punti mensili più vecchi non sono quindi più protetti. Un blocco più lungo ne protegge di più, ma occupa anche più dati.
I backup di file e di VM (Proxmox VE, Hyper-V, VMware) si ripristinano dalla copia come dall’originale; le copie delle immagini disco con l’agente da riga di comando. Copia ora avvia subito una copia.
Copia offline per piccoli uffici: il tipo di destinazione Dischi USB / rimovibili a rotazione (copie offline) trova i dischi in base all’etichetta del volume (BZBACKUP1, BZBACKUP2 …). Puntate un job di copia su di esso, scambiate i dischi ad es. ogni settimana e tenete quello scollegato in un luogo sicuro. Se nessun disco è collegato, l’esecuzione fallisce con un avviso.
Passo 6 — Test di ripristino e verifica dei dati
Un backup è dimostrato solo quando è stato ripristinato. In Impostazioni → Test di ripristino:
- Testa automaticamente il backup più recente di ogni job (settimanale per impostazione predefinita): un campione casuale di file del backup più recente viene ripristinato in una cartella temporanea, verificato byte per byte con i checksum archiviati e cancellato; per le immagini disco si verificano blocchi casuali. Così si mettono alla prova accesso allo storage, credenziali, chiave e dati.
- Verifica i dati archiviati (mensile per impostazione predefinita): ogni porzione di dati di ogni repository viene letta e verificata, il che rivela presto un disco del NAS che si sta guastando o il degrado silenzioso dei dati. Su S3 e Azure gira solo con Anche sull'archiviazione cloud (S3, Azure) attivo: scarica tutto, attenzione ai costi di download.
- I job di VM Proxmox possono aggiungere un test di avvio che avvia ogni VM dal backup con la rete scollegata.
Testa ripristino e Verifica i dati nella pagina di un job li avviano subito. I risultati compaiono in Attività e Report; un test fallito invia un avviso come ogni errore.
Passo 7 — Avvisi e rilevamento del ransomware
Una copia fuori sede che fallisce da settimane non è una copia. Configurate Impostazioni → Notifiche e-mail (verificate con Invia e-mail di test) e lasciate attivo Errori: un’e-mail per ogni esecuzione fallita con il motivo — backup, copie, ripristini e test di ripristino — più, se volete, un report giornaliero. Impostazioni → Chat e webhook invia lo stesso a Slack, Microsoft Teams o a qualsiasi endpoint HTTP. Sulla dashboard, Richiede attenzione elenca job falliti, pianificazioni e RPO mancati, agenti offline e storage pieni al 90 % o che lo saranno entro 30 giorni.
Ogni backup viene inoltre confrontato con la storia recente del suo job. È segnato come sospetto quando sono cambiati molti più file del solito, i nuovi dati non si comprimono più (i file cifrati sembrano casuali), il numero di file è calato di un terzo o più o la quantità di nuovi dati è balzata in alto. BackupZit invia allora un avviso, lo elenca tra i backup sospetti da esaminare e sospende la conservazione del job (La conservazione è sospesa), così gli ultimi backup puliti non vengono cancellati anche se continuano ad arrivare backup danneggiati. Dopo aver controllato la macchina, fate clic su Verificato — riprendi la conservazione.
Passo 8 — Proteggere la console
Lo storage immutabile protegge i backup; la console continua a decidere cosa salvare e conservare. In Impostazioni → Accesso e sicurezza richiedete l’autenticazione a due fattori per gli amministratori e attivate l’Approvazione a quattro occhi: eliminare job o destinazioni di storage, accorciare la conservazione, riprendere la conservazione dopo un backup sospetto e disattivare l’approvazione richiedono allora un secondo utente. Tenete la console nella rete interna, non pubblicate la porta 8443 su Internet e usate una VPN per l’amministrazione remota. Con Impostazioni → Backup della console la console esegue anche ogni giorno il backup di sé stessa su una destinazione di storage in rete.
Dopo un attacco
Se sono stati cancellati o sovrascritti dei backup, leggete lo storage com’era prima dell’attacco — in sola lettura, su S3 con Object Lock e sul repository protetto:
backupzit-agent snapshots --repo <repository> --as-of 2026-10-01T14:30
backupzit-agent restore --repo <repository> --as-of 2026-10-01T14:30 --target D:\Restore latest
Su un repository protetto l’amministratore può anche recuperare i file nascosti, così i backup proseguono normalmente:
backupzit-repo status
backupzit-repo undelete --since 2026-10-01T14:00
Limiti da conoscere
- L’immutabilità dura solo quanto il blocco. Un backup cancellato sparisce davvero alla fine del suo periodo; scegliete quindi il periodo pensando a quanto a lungo un attacco potrebbe passare inosservato.
- Un repository protetto è sicuro quanto il suo account root e l’accesso alla sua console, all’iDRAC/iLO o all’hypervisor.
- SMB, SFTP e i dischi locali non hanno un’immutabilità propria; combinateli con una copia immutabile o offline.
- I dati bloccati occupano spazio fino alla fine del blocco, anche dopo la cancellazione; senza la regola di lifecycle lo spazio S3 non viene liberato.
- L’immutabilità non ripulisce i dati: i file cifrati prima del backup vengono salvati cifrati. Ripristinate un punto precedente all’attacco: il rilevamento li conserva sospendendo la conservazione.
- Senza la chiave di ripristino nessuno può leggere i backup cifrati.
- L’approvazione a quattro occhi vale per la console; i gruppi di amministratori in Active Directory o Entra ID vanno protetti lì.
