Disaster Recovery di Rete per le PMI: Cosa Fare Quando la Connessione Cade

Per una PMI, un'ora senza connessione può significare ordini persi, assistenza bloccata, accesso remoto impossibile. Il disaster recovery di rete non è un lusso — è una scelta che si misura in euro di downtime evitato.

Cosa si intende per disaster recovery di rete

Il termine "disaster recovery" nel contesto delle reti indica l'insieme di procedure e infrastrutture che permettono di ripristinare la connettività (e i servizi che dipendono da essa) nel minor tempo possibile dopo un'interruzione.

I tre parametri chiave da definire prima di qualsiasi piano:

• RTO (Recovery Time Objective): quanto tempo massimo si accetta di stare offline
• RPO (Recovery Point Objective): quanti dati si può permettere di perdere (rilevante se si ha storage in cloud)
• MTTR (Mean Time To Repair): quanto ci vuole mediamente a ripristinare dopo un guasto

Per una piccola azienda il RTO accettabile è spesso 2-4 ore. Sotto quella soglia servono soluzioni di ridondanza attive. Oltre, basta una procedura di ripristino documentata.

I punti di guasto principali

Prima di scegliere la soluzione, identifica dove il sistema può rompersi:

• Ultimo miglio fisico: il cavo che va dall'edificio all'armadio stradale o alla CDZ. Se si taglia, non c'è nulla da fare lato router.
• Apparato CPE/ONT: il modem o l'ONT fornito dall'ISP. Guasto hardware, firmware corrotto, sovratensione.
• Router/firewall interno: il dispositivo che gestisce NAT, DHCP, firewall. Se cade, la rete interna smette di funzionare anche se il WAN è attivo.
• ISP backbone: guasti sull'infrastruttura del provider, rari ma possibili.
• Alimentazione: blackout che abbatte router, switch e server in sequenza.

Ogni punto di guasto ha una contromisura diversa.

Soluzioni di ridondanza WAN

Doppio ISP (active-passive o active-active)

La soluzione più efficace per garantire continuità: due linee di due provider diversi (o almeno su tecnologie diverse — es. fibra FTTH + FWA 5G).

Active-passive (failover): il router usa normalmente la linea A; se cade, commuta sulla B in automatico. Downtime di commutazione: da pochi secondi a 2-3 minuti a seconda del dispositivo.

Active-active (load balancing): entrambe le linee attive in contemporanea, il traffico viene distribuito. Più complesso da configurare, utile se entrambe le linee sono produttive.

Su MikroTik la configurazione failover si fa con recursive routing e distance differenziata:

/ip route add dst-address=0.0.0.0/0 gateway=<GW_ISP_A> distance=1 check-gateway=ping
/ip route add dst-address=0.0.0.0/0 gateway=<GW_ISP_B> distance=2 check-gateway=ping

Con check-gateway=ping il router verifica attivamente la raggiungibilità del gateway e commuta se non risponde.

FWA/4G come backup

Per le sedi dove non è possibile portare una seconda fibra, un router con SIM 4G/5G come backup è la soluzione più economica. Costo mensile: 10-30€ per una SIM dati con traffico sufficiente per uso di emergenza.

Router con doppio WAN (fibra + SIM): MikroTik LtAP, Teltonika RUT, GL.iNet con slot SIM.

Attenzione: molti operatori mobile usano CGNAT sulle SIM dati, il che rende impossibile ricevere connessioni in ingresso. Se hai bisogno di accesso remoto su backup 4G, devi prevedere una VPN verso un server con IP pubblico fisso.

Ridondanza degli apparati interni

Un secondo router in standby caldo non ha senso economico per la maggior parte delle PMI. Ha invece senso:

• UPS per tutti gli apparati di rete: router, switch, firewall, ONT. Un blackout di 30 minuti si gestisce con un UPS da 600VA. Costo: 80-150€. Guadagno: tutti i microcortes e i blackout brevi diventano invisibili.
• Switch con alimentazione ridondante: per ambienti critici (es. server room). Switch managed di fascia media supportano doppio alimentatore.
• Configurazione di backup del router: esporta la configurazione ogni settimana e salvala in un posto accessibile offline. Se un MikroTik si rompe, su un'unità identica puoi reimportare la configurazione in 5 minuti.

SD-WAN gestita: quando ha senso

Le soluzioni SD-WAN (es. Meraki, Fortinet, MikroTik con orchestrator) aggiungono uno strato di gestione centralizzata che permette failover automatico, visibilità unificata e policy di routing per applicazione.

Ha senso per:

• Aziende con più sedi da gestire in modo uniforme
• Scenari dove il failover deve essere trasparente anche per sessioni VoIP e VPN attive
• Ambienti con SLA stringenti

Per una sede singola con 10-20 utenti, la stessa ridondanza si ottiene con un router MikroTik configurato correttamente a un decimo del costo.

Il runbook: la parte più sottovalutata

Tutta l'infrastruttura ridondante è inutile se nessuno sa cosa fare quando scatta un allarme alle 8 di mattina. Un runbook è un documento operativo (anche un semplice file di testo) che risponde a queste domande:

• Chi chiamare per primo in caso di guasto
• Come verificare qual è il punto di guasto (checklist)
• Credenziali e accessi agli apparati (conservati in modo sicuro, es. KeePass)
• Procedure di ripristino passo passo per ogni scenario

Scenari minimi da documentare:

1. ONT/modem offline → procedura di reboot e verifica luci
2. Router non raggiungibile → come accedere in locale, come fare factory reset e reimportare config
3. Switch principale guasto → lista delle porte e dei dispositivi collegati per ricollegare in ordine
4. Blackout prolungato → priorità di ripristino degli apparati

Il runbook va testato almeno una volta l'anno, idealmente simulando il guasto in orario non produttivo.

Monitoring proattivo

Non aspettare che gli utenti segnalino il disservizio. Un sistema di monitoring base avvisa in anticipo (o appena accade) di qualsiasi problema:

• Zabbix o Uptime Kuma per check di disponibilità e latenza
• SNMP trap dai router MikroTik verso un sistema di alerting
• Alert via email o Telegram quando la linea cade o il failover si attiva

Anche un semplice script bash che fa ping ogni minuto e manda un messaggio Telegram se fallisce per 3 volte consecutive è meglio di nulla.

---

Un piano di disaster recovery non deve essere costoso. Serve chiarezza: sapere dove si rompe, avere una seconda via e una procedura scritta. Il 90% dei downtime prolungati nelle PMI non dipende dalla mancanza di ridondanza, ma dalla mancanza di un piano.