Backup & Disaster Recovery — Runbook unico a prova di dummy

✅ Questo è L'UNICO documento di riferimento per backup e disaster recovery del sistema. I vecchi documenti (Piano backup, NAS Backup Suite, Rotazione REAR) sono stati fusi in questo: non usarli. ⚠️ Stato verificato: 26/09/2026. Se cambi qualcosa, aggiorna anche questo documento (regola 1.6.2).

🚦 In 30 secondi: cosa succede ogni notte

1. 03:00 — Il NAS principale (sempre acceso) sveglia il NAS di backup (di solito spento), copià i file con versione (giornaliere/settimanali/monthly), manda un report per e-mail e lo riSpegne di nuovo.
2. 03:35 — La ISO di ripristino viene "ruotata": lunedì il PC, martedì il NAS backup, mercoledì il NAS principale.
3. 08:00 — Il watchdog (sentinella indipendente) ricontrolla che il ciclo notturno sia partito bene. Se qualcosa è storto, invia un alert di backup (non duplica le mail già inviate).

In una frase: ogni notte si fa una copia versioneata dei file; ogni mattina si fa una ISO di ripristino; una sentinella controlla che tutto sia andato a buon fine.

🖥️ I tre host e i loro IP

🛡️ Le 4 linee di difesa (cosa, come, dove, quando)

⚙️ I componenti e dove stanno

Su NAS principale (nas64 — hub, sempre acceso)

Su NAS backup (nas64sas — il motore)

🔁 Il ciclo notturno (03:00) — passo dopo passo

1. systemd timer (03:00) su NAS principale avvia nas64sas-orchestrator.
2. Lock: se un ciclo è già in corso, la nuova esecuzione termina subito (exit 75) — niente si tocca.
3. Sveglia: se il NAS backup non risponde, wakeonlan; attesa SSH fino a 300s (2 min).
4. Precheck: il motore verifica config, RAID, accesso sorgente.
5. Backup: si lancia su NAS backup nas64sas-backup --no-shutdown normal.
   • Perché --no-shutdown? Perfar leggere il report prima di spegnere: scelta architetturale, non una disabilitazione del shutdown.
6. Il motore: preflight → dataset in ordine → rsync versionato → promozioni hardlink → stato → report → mail.
7. Validazione report: l'orchestratore recupera last-result.txt del motore, lo valida, lo salva localmente.
8. Poweroff: ordina al NAS backup di spegnersi (systemctl poweroff) e conferma che è offline.
9. Risultato finale in /var/lib/nas64sas-orchestrator/last-result.txt.

Esecuzione manuale (a mano, in qualsiasi momento):

# su NAS principale: ciclo completo manuale
sudo /usr/local/sbin/nas64sas-orchestrator
# oppure
systemctl start nas64sas-orchestrator

📅 Il ciclo REAR (03:35) — passo dopo passo

Per ogni host (lun PC, mar NAS backup, mer NAS principale):

1. Ping: era già acceso? → lo nota nel log e non lo tocca mai.
2. Se spento: wakeonlan + attesa boot (max 15 min).
3. Lancia rear mkbackup (remoto via ssh; per il NAS principale, locale).
4. Monitora l'ISO fresca (max 2h, controllo ogni 1 min).
5. Notifica per mail (OK/FAIL; su FAIL, invia anche la coda del log).
6. Shutdown SOLO se era stato acceso dal script.

👁️ Il watchdog (08:00)

Ogni mattina, su NAS principale:

• Ricontrolla il risultato del ciclo notturno.
• Se è recente e coerente → silenzio.
• Se anomalia (ciclo mancante, report fallito, poweroff non confermato) → alert di fallback per mail.
• Regola anti-duplica: se il motore ha già inviato mail con notify_status=ACCEPTED, il watchdog non rinvia.

📊 Dove guardare l'esito (monitoring)

Da NAS principale (nas64)

# log orchestrazione
ls -t /var/log/nas64sas-orchestrator/*.log | head -5
tail -n 100 /var/log/nas64sas-orchestrator/orchestrator-$(date +%Y-%m-%d)_{*} 2>/dev/null

# esito ultimo ciclo
cat /var/lib/nas64sas-orchestrator/last-result.txt

# log REAR
ls -t /var/log/rear-rotation/*.log | head -5

Da NAS backup (nas64sas)

# esito ultimo ciclo motore
cat /var/lib/nas-backup/last-result.txt

# log di ogni run
ls -t /var/log/nas-backup/*.log | head -5

ISO REAR

# su nas64
find /export/DRD_Backup -maxdepth 2 -name "rear-*.iso" -ls

Dashboard (dbsoft)

La dashboard mostra i run notturni leggendo i log in /var/log/nas64sas-orchestrator. Se non appare niente → il mount è staccato → docker restart dashboard.

🎛️ La configurazione (cosa e dove cambiare)

Dataset e retention (file /etc/nas-backup/nas-backup.conf su NAS backup)

Calendario: daily=ogni giorno · weekly=lunedì · monthly=giorno 1. Hardlink: le generazioni puntano agli stessi blocchi → i file invariati non occupano spazio doppio.

Variabili chiave

AUTO_SHUTDOWN=1             # rispegna NAS backup a fine ciclo (anche in caso d'errore)
MIN_FREE_GB=1000            # non parte se il RAID backup ha meno di 1000 GB liberi
NOTIFY_EMAIL="hermesgirl@busce.it"
# ---- ddfull (DISABILITO) ----
NAS64SAS_OMV_BACKUP_ENABLED=0
NAS64SAS_OMV_BACKUP_OUTPUT_DIR=/srv/.../DR_NAS64/omvbackup
# ---- REAR interno al motore (DISABILITO) ----
NAS64SAS_REAR_ENABLED=0     # il REAR lo fa la rotazione cron, NON il motore

Dopo ogni modifica alla config: bash -n /etc/nas-backup/nas-backup.conf (sintassi) poi check.

🛠️ Comandi per dummy (tutti da root)

Guardare come sta (NON tocca niente)

# su NAS backup: controllo completo (config, RAID, accesso, generazioni). Il "termometro".
/usr/local/sbin/nas64sas-backup check

# esito ultimo ciclo
cat /var/lib/nas-backup/last-result.txt

Far girare un backup a mano

# su NAS backup
/usr/local/sbin/nas64sas-backup normal              # normale (rispetta il calendario)
/usr/local/sbin/nas64sas-backup normal --dry-run    # prova a vuoto
/usr/local/sbin/nas64sas-backup seed-one <dataset>  # seed iniziale di un dataset
/usr/local/sbin/nas64sas-backup oneshot <dataset>   # copia one-shot in ARCHIVIO (pre-upgrade)
# su NAS principale
sudo /usr/local/sbin/nas64sas-orchestrator          # ciclo completo manuale

Kill-switch (sospendere SOLO ddfull + REAR; i dataset normali continuano)

touch /etc/nas-backup/schedule.suspend   # sospende ddfull + REAR
rm    /etc/nas-backup/schedule.suspend   # riattiva

🚨 Ripristini — quando va male

Ripristino di un file specifico (esempio):

# su NAS backup: trova la ultima generazione disponibile
ls -lt /BACKUP_NAS64/home/daily.*/ 2>/dev/null
# ricopri il file nel posto giusto
scp root@192.168.1.20:/BACKUP_NAS64/home/daily.3/caminio/file.txt ./

⚠️ Cosa è ATTIVO e cosa è SPENTO (stato corrente, 26/09/2026)

• ✅ ATTIVO: backup notturno file (03:00), rotazione REAR (03:35 lun/mar/mer), watchdog (08:00).
• ❌ SPENTO: OMV ddfull del disco NAS backup (NAS64SAS_OMV_BACKUP_ENABLED=0) — con il disco attuale (1TB) impiega 9-10 ore; si riaccende solo con un disco di sistema più piccolo.
• ❌ SPENTO: REAR interno al motore (NAS64SAS_REAR_ENABLED=0) — il REAR lo fa la rotazione cron, non il motore.
• 🔄 Retention REAR: 2 generazioni per host (in .../<host>.old/).

🧠 Curiosità (per capire, non per operare)

• Perché il NAS backup sta spento? La copia di sicurezza: spenta non si rompe, non consuma. Si accende solo per backuppare.
• Perché hardlink tra daily/weekly/monthly? I file invariati non occupano spazio doppio: le generazioni puntano agli stessi blocchi.
• Perché REAR + ddfull? REAR = ISO piccola e veloce per riavviare. ddfull = copia byte-per-byte lenta ed enorme → resta OFF.
• Perché --no-shutdown nell'orchestrazione? Perfar leggere il report PRIMA di spegnere: scelta architetturale, non una disabilitazione del shutdown.

📝 Regole di manutenzione

1. Un solo documento di riferimento → sempre questo.
2. Ogni modifica strutturale significativa a un NAS: (a) backup dello script, (b) bash -n, (c) test read-only/dry-run, (d) test controllato, (e) test restore, (f) aggiornamento di questo documento.
3. Dopo ogni modifica alla retention/config: verifica che i dataset non "spariscano" (regola retention, v.5.4).
4. Cancellazione dati: mai rm diretto — si usa solo rm -- + backup + verifica.
5. Ogni backup "a mano" va annotato in questo runbook.

Runbook unico a prova di dummy — 26/09/2026. Fusione di: "Piano backup e disaster recovery NAS", "NAS Backup Suite", "Backup & DR — NAS principale + NAS di backup + PC fisso", "Rotazione REAR settimanale".