Backup e monitoraggio¶
Backup (stato al 27/10/2026)¶
| Cosa | Come | Frequenza | Conservazione | Dove |
|---|---|---|---|---|
| Tutte le VM Proxmox | vzdump in modalità snapshot, compressione zstd, mail a IT a ogni esecuzione |
sabato alle 01:00 | 3 backup (3 settimane) | NAS in ufficio (QNAP), via VPN e NFS, non raggiungibile da internet |
| Registrazioni chiamate trombe | script | giornaliera | — | S3 videosorveglianzasync |
| Log dei box | invio periodico | — | — | S3 it.bsq.mdm.logs |
| MySQL del midserver | nessun backup dedicato | — | — | — |
| Redis del midserver | snapshot RDB interno, volume anonimo | 1 min – 1 h | 1 | stessa VM |
| Configurazione pfSense | solo dentro lo snapshot della VM | settimanale | 3 | NAS |
Token eWeLink (data/tokens.json) |
solo dentro lo snapshot della VM | settimanale | 3 | NAS |
Perché solo settimanali: il MySQL del midserver conteneva solo log, quindi Franco riteneva sufficiente il backup settimanale. Con allarmi e foto servono dump più frequenti (Michele, 28/10).
Lacune: - Con un backup settimanale si può perdere fino a una settimana di modifiche (configurazioni, trombe, peer VPN). - Nessun dump logico di MySQL: il ripristino richiede di ripristinare tutta la VM. - Il ripristino si fa da Proxmox (Backup → Restore, proxmox.md); è stato usato ad aprile 2026 per la migrazione tra le macchine e per copie veloci del sistema (Michele, 30/10). - Proposta già fatta da Michele: un disco aggiuntivo da Netsons per backup più frequenti delle VM critiche.
Monitoraggio (stato al 27/10/2026)¶
- Il controllo dell'infrastruttura lo fa il Raspberry di Michele (
192.168.200.220, base datisystem_controls, 18 server e servizi): gli avvisi arrivano su Telegram nel gruppo "Controllo Infrastrutture", che dal 30/10 riceve anche l'ufficio IT (Michele, 30/10). L'elenco dei controlli è nella tabellasystem_controls.system; cosa fare a ogni avviso e chi è reperibile dopo l'uscita di Michele non è deciso (M-4); il Raspberry non ha backup (R13). - Il controllo online/offline degli impianti lo fanno il Raspberry di Michele e il pannello MDM (box per box).
- Lo stack del repository
monitoring(Grafana, Prometheus, Loki, Tempo, Alertmanager su Telegram) gira solo su Coolify dev e controlla qAlarm e midserver v3 di dev, compresa la metrica degli impianti offline del midserver v3. Non controlla pfSense, VPN, ServerIT, il midserver v2, OME, ewelink, i box. Dettagli e problemi (token Telegram nel repository, Grafana dev anonimo): monitoring.md. - L'indirizzo
192.168.200.202nella configurazione del pannello di produzione non corrisponde a niente di attivo (M12). - Controlli manuali sugli impianti fatti da una persona (da marzo 2026).
Proposta (fuori scope per ora)¶
Il monitoraggio non fa parte del piano attuale: R1 è segnalato come problema aperto. Proposta da riprendere in futuro:
Anche Michele (28/10) suggerisce qualcosa come Uptime Kuma, per tenere traccia di online/offline di ogni servizio Docker. Lo stack monitoring esiste ed è attivo in dev, ma non è mai stato messo in esercizio in produzione. La soluzione ideale, che riusa quello stack, è in monitoring.md.
Un monitor esterno semplice (per esempio Uptime Kuma) che controlla:
- pfSense e VPN (ping su 172.16.16.1, raggiungibilità di un box di riferimento);
- midserver (porta 5000 da VPN, poi /health con la v3);
- pannello e API (HTTPS pubblici);
- OME (porta 3333);
- ewelink (?action=health);
- spazio disco di ServerIT e dell'host;
e avvisa su un canale che qualcuno legge di notte (Telegram o email + telefono).