Vai al contenuto
Home » 🧭 Howto – Guide Tecniche per Tor, Privacy e Sicurezza » 📦 Debian 12 Backup Node – POC per Homelab sicuro e isolato » 📁 Debian 12 Backup Node – Rsync Secure Setup per Homelab Tor

📁 Debian 12 Backup Node – Rsync Secure Setup per Homelab Tor

Introduzione

In un’infrastruttura privata, soprattutto se operante su rete Tor e priva di esposizione a Internet tradizionale, è fondamentale implementare un sistema di backup sicuro, resiliente e facilmente gestibile. Questa guida ti accompagna passo dopo passo nella configurazione di un nodo di backup basato su Debian 12 Minimal, pensato per ambienti Homelab con particolare attenzione alla privacy e all’isolamento della rete.

Il documento si rivolge a sistemisti, professionisti IT e utenti avanzati che operano in ambienti virtualizzati (Proxmox VE, VirtualBox, VMware) o in contesti air-gapped. L’obiettivo è costruire una base solida per ambienti di test e proof-of-concept (POC), espandibile verso scenari di produzione. Per chi desidera un’implementazione più completa, estendibile a contesti aziendali, metto a disposizione i miei servizi professionali pensati per aziende e privati.

📌 Nota tecnica: questa guida si concentra esclusivamente sulla configurazione e messa in sicurezza del server di backup. Le logiche di backup avanzato (come versionamento, compressione selettiva, snapshot incrementali e gestione del ripristino) dovranno essere implementate direttamente sui nodi client, ovvero sulle VM o sui server che inviano i dati.

Per evitare che questa guida diventasse eccessivamente lunga o dispersiva, ho scelto un approccio pratico e focalizzato. Una guida separata illustrerà come configurare in modo strutturato e professionale i server client che devono eseguire i backup verso questo nodo centralizzato.

Nell’esempio proposto, la chiave SSH viene generata come root sulla VM client e copiata nell’utente dedicato sul server di backup: questa è una scorciatoia accettabile in un POC, ma in produzione si raccomanda un setup più rigoroso con identità coerenti.

📅 Prerequisiti

Per una gestione dei nomi più chiara e manutenibile, aggiungi nel file /etc/hosts di ogni VM client la seguente riga:

172.16.16.250   backupnode-tor

Questo ti permette di usare backupnode-tor al posto dell’indirizzo IP nei comandi rsync e SSH, rendendo la configurazione più leggibile e resistente a modifiche future di rete.

  • Debian 12 Minimal installato e aggiornato
  • Utente con privilegi sudo (backupadmin)
  • Accesso root via console
  • Connessione alla rete LAN privata (es. 172.16.16.0/24)
  • Cifratura disco con LUKS (consigliata)
  • VLAN dedicata per il traffico di backup (consigliata, es. VLAN 100)

🔒 Hardening iniziale del server di backup

🔹 Aggiornamento del sistema

Assicurati che il sistema sia aggiornato:

apt update && apt upgrade -y

🔹 Installazione dei pacchetti essenziali

Installa gli strumenti necessari per sicurezza, sincronizzazione e diagnostica:

apt install -y openssh-server rsync sudo ufw fail2ban vim htop net-tools

🔥 Configurazione del firewall (UFW)

Limitiamo il traffico in ingresso consentendo solo connessioni SSH dalla LAN:

ufw default deny incoming
ufw default allow outgoing
ufw allow from 172.16.16.0/24 to any port 22 proto tcp
ufw enable

Verifica lo stato:

ufw status verbose

🔐 Messa in sicurezza di SSH

Modifica /etc/ssh/sshd_config per rafforzare l’accesso remoto:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
UsePAM yes

Applica le modifiche:

systemctl reload sshd

📂 Preparazione dello storage di backup sul server

Creiamo lo spazio protetto in cui le VM client salveranno i propri dati:

mkdir -p /backup
chmod 711 /backup

⚙️ Abilitazione accesso SSH del PC client al server di backup

Genera una nuova coppia di chiavi SSH sul PC client:

ssh-keygen -t ed25519
cat ~/.ssh/id_ed25519.pub

🔸 Sul server di backup:

mkdir -p /home/backupadmin/.ssh
vi /home/backupadmin/.ssh/authorized_keys

Incolla nel file authorized_keys la chiave pubblica generata sul PC client (il contenuto del file ~/.ssh/id_ed25519.pub), quindi imposta i permessi:

chown -R backupadmin:backupadmin /home/backupadmin/.ssh
chmod 700 /home/backupadmin/.ssh
chmod 600 /home/backupadmin/.ssh/authorized_keys

🔧 SSH config sul PC client per connessione al server di backup

Per semplificare le connessioni SSH, crea o modifica il file ~/.ssh/config così:

Host backupnode-tor
    HostName backupnode-tor
    User backupadmin
    IdentityFile ~/.ssh/id_ed25519_tor
    ServerAliveInterval 30
    ServerAliveCountMax 120
    StrictHostKeyChecking no
    UserKnownHostsFile=/dev/null
    Port 22

A questo punto, dal PC client da cui amministri il server di backup, puoi collegarti rapidamente con il comando:

ssh backupnode-tor

👤 Provisioning utenti dedicati per ogni VM client (sul server di backup)

Ogni VM che invia dati al server di backup dovrebbe avere un proprio utente dedicato. Esempio con la VM stealthmail:

sudo useradd -m -d /home/stealthmail -s /bin/bash stealthmail
sudo passwd stealthmail
sudo chown stealthmail:stealthmail /home/stealthmail
sudo chmod 700 /home/stealthmail

Dopo aver creato l’utente, assicurati di predisporre anche la directory di destinazione sul server di backup dove verranno salvati i dati:

sudo mkdir -p /backup/stealthmail
sudo chown stealthmail:stealthmail /backup/stealthmail
sudo chmod 700 /backup/stealthmail

🔑 Configurazione chiavi SSH per le VM da cui eseguire i backup

Su ogni nodo da cui vogliamo eseguire i backup (es. server o VM di produzione):

🔸 Genera la chiave:

ssh-keygen -t ed25519

🔸 Visualizza il contenuto della chiave pubblica:

cat ~/.ssh/id_ed25519.pub

🔸 Copia manualmente questo contenuto nel file authorized_keys sul server di backup:

Sempre tramite l’utente backupadmin sul server di backup:

sudo mkdir -p /home/stealthmail/.ssh
sudo vi /home/stealthmail/.ssh/authorized_keys

Incolla la chiave pubblica appena generata sulla VM client, ovvero il contenuto del file ~/.ssh/id_ed25519.pub, salva ed esci. Poi imposta i permessi:

sudo chown -R stealthmail:stealthmail /home/stealthmail/.ssh
sudo chmod 700 /home/stealthmail/.ssh
sudo chmod 600 /home/stealthmail/.ssh/authorized_keys

Ora le VM saranno abilitate a trasferire i propri dati in sicurezza via rsync/SSH.

🔢 Best Practices

  • Utilizzare una VLAN dedicata per il traffico di backup
  • Consentire l’accesso SSH solo tramite chiave pubblica
  • Attivare Fail2Ban per mitigare attacchi brute-force
  • Cifrare lo storage con LUKS o equivalente
  • Implementare backup incrementali e compressi per efficienza

🚀 Backup rsync automatizzato con compressione e retention

Una volta configurata l’autenticazione SSH tra la VM client e il server di backup, è possibile eseguire un backup manuale o automatizzato utilizzando rsync.

🔧 Prima di procedere: Verifica che rsync sia installato sulla VM client, e crea la directory di log locale dove salvare l’output del backup:

sudo apt install rsync -y
sudo mkdir -p /var/log/rsync-backups

💡 Inoltre, accertati che il file /etc/hosts della VM client contenga il nome del server di backup, per evitare di dover specificare ogni volta l’indirizzo IP:

172.16.16.250   backupnode-tor

🔄 Esempio di backup compressi giornalieri

Per evitare la sovrascrittura accidentale di dati, il backup crea un archivio .tar.gz con data e lo trasferisce nella directory remota /backup/stealthmail/. Si manterranno manualmente i backup degli ultimi 15 giorni.

🧪 Verifica manuale prima del cron

Prima di pianificare l’esecuzione automatica, esegui un test manuale per verificare che il backup funzioni correttamente:

TODAY=$(date +%Y-%m-%d)
ARCHIVE="/tmp/etc-backup-$TODAY.tar.gz"
LOGFILE="/var/log/rsync-backups/rsync_backup-$TODAY.log"

tar -czf "$ARCHIVE" /etc

date >> "$LOGFILE"
rsync -avh --stats "$ARCHIVE" stealthmail@backupnode-tor:/backup/stealthmail/ >> "$LOGFILE" 2>&1

rm "$ARCHIVE"

✅ Riscontro visivo del backup trasferito

Dopo aver eseguito il comando manuale, è possibile collegarsi al server di backup per verificare la corretta ricezione del file .tar.gz. Un output simile al seguente conferma che l’archivio è stato trasferito con successo:

root@BackupNode-Tor:/backup/stealthmail# ll /backup/stealthmail/
total 752
-rw-r--r-- 1 stealthmail stealthmail 768514 May  1 03:26 etc-backup-2025-05-01.tar.gz

Puoi anche estrarre l’archivio per controllare che i contenuti e i permessi siano stati mantenuti correttamente:

root@BackupNode-Tor:/backup/stealthmail# tar zxf etc-backup-2025-05-01.tar.gz
root@BackupNode-Tor:/backup/stealthmail# ll
total 756
drwxr-xr-x 86 root        root          4096 May  1 02:49 etc
-rw-r--r--  1 stealthmail stealthmail 768514 May  1 03:26 etc-backup-2025-05-01.tar.gz
root@BackupNode-Tor:/backup/stealthmail# ll etc/
total 808
-rw-r--r-- 1 root root    3040 May 25  2023 adduser.conf
-rw-r--r-- 1 root root      44 Apr 28 12:27 adjtime
-rw-r--r-- 1 root root      51 Apr 28 12:57 aliases
-rw-r--r-- 1 root root   12288 Apr 28 12:57 aliases.db
drwxr-xr-x 2 root root    4096 Apr 30 13:55 alternatives
drwxr-xr-x 8 root root    4096 Apr 28 12:57 apache2
...

Questo dimostra che i file all’interno dell’archivio mantengono i permessi originali, essenziali in caso di ripristino.

🗓️ Automazione tramite cron

Per rendere il backup ricorrente (ad esempio ogni giorno alle 2:00 del mattino) e pulire i file più vecchi di 15 giorni in un’unica operazione, aggiungi la seguente riga al crontab dell’utente root sulla VM client:

crontab -e

E inserisci:

0 2 * * * TODAY=$(date +\%Y-\%m-\%d); ARCHIVE="/tmp/etc-backup-$TODAY.tar.gz"; LOGFILE="/var/log/rsync-backups/rsync_backup-$TODAY.log"; tar -czf "$ARCHIVE" /etc; date >> "$LOGFILE"; rsync -avh --stats "$ARCHIVE" stealthmail@backupnode-tor:/backup/stealthmail/ >> "$LOGFILE" 2>&1; rm "$ARCHIVE"; ssh stealthmail@backupnode-tor 'find /backup/stealthmail/ -type f -name "*.tar.gz" -mtime +15 -delete'

✅ In questo modo:

  • Ogni giorno viene creato un archivio compresso della directory /etc
  • Il file viene trasferito al server di backup e tracciato con un log
  • I backup più vecchi di 15 giorni vengono automaticamente eliminati

Il tutto in un unico processo schedulato, mantenendo un sistema di backup completo, sicuro, tracciabile e con una retention controllata

♻️ Gestione avanzata dei log con logrotate

📝 Nota: questa configurazione va eseguita sulla VM client, ovvero sulla macchina che esegue i backup e genera i file di log.

Per completare la gestione del sistema di backup, è importante assicurarsi che i file di log generati da rsync vengano mantenuti ordinati e compressi nel tempo.

📂 Crea il file di configurazione

sudo vi /etc/logrotate.d/rsync-backups

✍️ Inserisci il contenuto seguente:

/var/log/rsync-backups/*.log {
    weekly
    rotate 52
    compress
    missingok
    notifempty
    create 0640 root adm
    dateext
    dateformat -%Y-%m-%d
}

Spiegazione rapida:

  • weekly: ruota i log ogni settimana
  • rotate 52: conserva i log per 52 settimane (1 anno)
  • compress: comprime i file log ruotati usando gzip
  • dateext + dateformat: aggiunge la data al nome del file ruotato (es. log-2025-05-01.gz)
  • missingok, notifempty, create: gestiscono assenza log, log vuoti e permessi

🔧 Verifica la configurazione

Puoi testare senza eseguire realmente la rotazione:

sudo logrotate -d /etc/logrotate.d/rsync-backups

Oppure forzare una rotazione immediata:

sudo logrotate -f /etc/logrotate.d/rsync-backups

Assicurati che il servizio logrotate.timer (in sistemi con systemd come Debian 12) sia attivo:

systemctl status logrotate.timer

In questo modo, i tuoi log saranno compressi settimanalmente, rinominati con la data e conservati in modo ordinato senza saturare lo spazio su disco.

✅ Conclusione

Questa configurazione rappresenta un Proof of Concept (POC) solido, sicuro e documentato per un nodo di backup basato su Debian 12, ideale per ambienti Homelab che operano su rete Tor o in contesti isolati. È pensata per chi desidera una soluzione semplice, efficace e completamente autogestita, pur senza ricorrere a software di backup enterprise.

🔧 Come migliorarlo ulteriormente

Per portare questa soluzione a un livello più professionale:

Da implementare sui client di backup (le VM che inviano i dati):

  • Backup incrementali → riducono lo spazio occupato e permettono versionamento
  • Verifica integrità → calcolo e confronto di checksum (es. SHA256) prima e dopo rsync
  • Ripristino facilitato → script di restore automatico e gestione versioni
  • Notifiche automatiche → invio di report tramite email o Telegram

Da implementare sul server di backup:

  • Replica offsite → sincronizzazione sicura su nodo remoto o storage dedicato via VPN
  • Controllo spazio disco e alert → per evitare blocchi operativi
  • Automazioni di retention avanzate → oltre la semplice cancellazione dopo X giorni

💼 Se desideri una soluzione completa e professionale, oppure supporto per l’evoluzione di questo POC in un ambiente aziendale, puoi affidarti ai miei servizi IT per aziende e privati.