- Inizio
- Competenze
- Datacenter e backup
Datacenter, backup e continuità operativa
Gestiamo virtualizzazione Proxmox VE e VMware vSphere, dal singolo host ai cluster su più datacenter o su due siti, con lo storage che c’è sotto (Fibre Channel, iSCSI, array in replica sincrona, ZFS) e i backup Veeam. Seguiamo anche database, posta, cloud pubblico e server dedicati, e costruiamo il monitoraggio.
Il lavoro più documentato riguarda i guasti: volumi illeggibili, ripartenze dopo un blackout, siti di disaster recovery spenti e riaccesi da remoto, database bloccati. Si diagnostica in sola lettura fino alla causa, si lavora su una copia, si verifica il risultato e non il comando.
Cluster Proxmox VE
Installiamo e gestiamo cluster Proxmox VE su server dedicati, anche in più datacenter: ZFS locale replicato fra i nodi, quorum con un terzo voto su un altro sito, rete privata di livello 2 fra datacenter, VLAN trasportate fra i nodi. Regoliamo memoria e I/O e scegliamo l’hardware sulle misure di carico, non sul catalogo.
Tecnologie e prodotti
- Proxmox VE 8 e 9
- ZFS
- Corosync e QDevice
- KSM
- QEMU guest agent
- Server dedicati e reti private dei provider
Esempi
-
Cluster di servizi per più clienti (5 nodi in 4 datacenter) In esercizio
La memoria che la cache del file system si prendeva
- Il problema
- Su un nodo la cache di ZFS occupava 116 GB di RAM e lo swap era al 100%; durante i backup un pool di dischi meccanici portava il carico a 62 su 16 thread.
- Cosa abbiamo fatto
- Un limite alla cache per ogni nodo e la deduplica della memoria (KSM); un tetto di scrittura sui dischi dei repository di backup.
- Risultato
- RAM libera passata da 12,9 a 68 GB sul nodo più carico; durante i backup il carico è sceso da 62 a 22.
-
Piattaforma applicativa su server dedicati In esercizio
Un cluster nuovo dimensionato sulle misure
- Il problema
- Scegliere il secondo e il terzo nodo di un cluster senza comprare più del necessario.
- Cosa abbiamo fatto
- Proxmox VE 9 installato attraverso le API del provider. Il secondo nodo scelto sul carico reale (0,36 core di media), sulle prestazioni del singolo core e sulla compatibilità delle CPU virtuali. Due nodi più un voto esterno, repliche ZFS ogni 15 minuti su una rete privata misurata a 918-947 Mbit/s.
- Risultato
- Il terzo nodo, installato in 15 minuti, ha preso il posto del voto esterno.
VMware vSphere
Amministriamo e diagnostichiamo ambienti vSphere, dall’host isolato a più cluster su due siti con vSAN: HA, DRS, EVC, vMotion, vSphere Replication. Automatizziamo con pyVmomi, le API di vCenter e PowerCLI, anche per installare macchine virtuali senza aprire la console.
Tecnologie e prodotti
- VMware vSphere ed ESXi, da 5.5 a 8.0
- vCenter e vSAN
- HA, DRS, EVC, vMotion
- vSphere Replication
- PowerCLI e pyVmomi
Esempi
-
Gruppo industriale, sede estera Consegnato
vMotion bloccato da un modulo del kernel
- Il problema
- In una sede estera con 2 host e 31 macchine virtuali le migrazioni a caldo non funzionavano.
- Cosa abbiamo fatto
- Tolte le ISO montate su 7 macchine, azzerato con migrazioni a freddo lo stato di migrazione corrotto di 26 macchine; la causa radice era un modulo del kernel ESXi non caricato su uno degli host.
- Risultato
- vMotion di nuovo funzionante nei due sensi: 14 macchine ribilanciate a caldo in 11,6 minuti, senza fermo.
-
Azienda manifatturiera Consegnato
Due host spostati in un cluster con EVC in quattro minuti
- Il problema
- Riorganizzare un vCenter con 9 host e 97 macchine virtuali portando due host in un cluster con compatibilità di CPU uniforme.
- Cosa abbiamo fatto
- Uno studio completo dell’ambiente con analisi critica, poi lo spostamento affidato a uno script provato.
- Risultato
- Quattro minuti in tutto, macchine ferme per circa tre, indirizzi invariati.
Migrazioni di piattaforma e di servizi
Spostiamo macchine virtuali e servizi fra hypervisor, provider e versioni del sistema operativo con fermi brevi e misurati: censimento delle dipendenze, prova generale, vecchio sistema pronto come ritorno, verifica per conteggio, DNS aggiornati via API.
Tecnologie e prodotti
- Veeam e qemu-img
- Proxmox VE e VMware ESXi
- cloud-init e netplan
- Postfix
- API DNS di più provider
Esempi
-
Infrastruttura di servizi su cloud Consegnato
Un hub VPN spostato senza interrompere nessuno
- Il problema
- Dismettere un host di virtualizzazione presso un provider e portarne i servizi su un nodo di un altro provider, compreso l’hub VPN di molti utenti.
- Cosa abbiamo fatto
- L’hub VPN (33 client OpenVPN e 63 peer WireGuard) è stato spostato un client alla volta. Le macchine ripristinate da backup sono state adattate al nuovo hypervisor e 35 record DNS su tre provider ripuntati via API.
- Risultato
- Ogni client riconnesso in circa 10 secondi, zone DNS ricontrollate tutte, vecchio host verificato vuoto e dismesso.
-
Applicazione web con database MongoDB Consegnato
Un database spostato con 41 secondi di fermo
- Il problema
- Portare il backend applicativo da una macchina virtuale a un server nuovo senza perdere dati.
- Cosa abbiamo fatto
- La prova generale ha fatto emergere un percorso scritto nel codice, corretto prima del passaggio. Durante la propagazione del DNS la vecchia macchina ha fatto da reverse proxy verso la nuova.
- Risultato
- Fermo di 41 secondi, 82.954 record prima e dopo.
Storage, SAN e file system
Lavoriamo su SAN Fibre Channel, iSCSI con multipath, array in replica sincrona fra due siti, storage che virtualizza altri array e NAS. Facciamo dismissioni ordinate e analizziamo errori e prestazioni su ZFS, btrfs, ReFS e LVM.
Tecnologie e prodotti
- Brocade FOS
- Dell PowerStore
- NetApp ONTAP
- IBM FlashSystem
- HPE StoreOnce
- open-iscsi e multipath
- ZFS, btrfs, ReFS, LVM
Esempi
-
Gruppo industriale In esercizio
Da un percorso a quattro, senza fermare il cluster
- Il problema
- Durante la manutenzione di un array, 12 macchine virtuali hanno avuto errori di I/O per 23 minuti.
- Cosa abbiamo fatto
- L’analisi in sola lettura ha trovato la causa: destinazioni iSCSI sbagliate nella configurazione, un solo percorso per nodo verso i due array in replica. Correzione a caldo, un nodo alla volta.
- Risultato
- Da uno a quattro percorsi per volume, verificati anche dopo un riavvio.
-
SAN su due fabric Consegnato
Uno switch Fibre Channel sostituito senza conflitti
- Il problema
- Sostituire uno switch guasto in una SAN di quattro switch su due fabric.
- Cosa abbiamo fatto
- Lo switch nuovo è stato portato alla versione del fabric con quattro aggiornamenti in sequenza; licenze trasferite dall’unità guasta.
- Risultato
- Unione al fabric senza conflitti di zoning.
-
Azienda manifatturiera Consegnato
Due cluster di storage dismessi senza sorprese
- Il problema
- Spegnere due cluster NetApp (quattro controller) senza togliere niente a nessuno.
- Cosa abbiamo fatto
- Inventario completo attraverso le API, poi la verifica che nessun sistema li usasse più.
- Risultato
- Dismissione fatta solo dopo aver visto che nulla rispondeva più.
Backup con Veeam
Gestiamo impianti Veeam per macchine VMware e Proxmox, agent, Microsoft 365, nastri, appliance di deduplica, repository ReFS e snapshot degli array. Curiamo capacità, conservazione, catene di job e cambi di versione, con automazione via REST e PowerShell. E controlliamo che i backup esistano, non solo che il job sia verde.
Tecnologie e prodotti
- Veeam Backup & Replication 12 e 13
- Veeam Agent e Veeam Backup for Microsoft 365
- HPE StoreOnce Catalyst
- ReFS con fast clone
- Librerie LTO-7 e LTO-9
- Snapshot Dell PowerStore
Esempi
-
Azienda manifatturiera Consegnato
Un'appliance di backup piena, svuotata senza perdere copie
- Il problema
- L’appliance di deduplica da 32 TB era a zero byte liberi e i backup di oltre 50 job fallivano.
- Cosa abbiamo fatto
- Prima di cancellare abbiamo verificato, macchina per macchina, dove esisteva un’altra copia. Abbiamo anche scoperto che lo spazio mostrato dalla console era una cache sbagliata (898 GB contro 12.643 reali): da allora si decide sulla fonte diretta. Poi 24 job nuovi dagli snapshot dell’array via Fibre Channel.
- Risultato
- Liberati 5,9 TiB sull’appliance e oltre 14 TB su un repository ReFS; backup ripartiti.
-
Azienda manifatturiera Consegnato
Un job fallito 211 volte di fila
- Il problema
- Un job di backup falliva sempre, e nessuno trovava il perché.
- Cosa abbiamo fatto
- Dai log dei singoli task: fallivano tutti quelli che passavano da un certo proxy (160 su 160) e riuscivano tutti gli altri (269 su 269). Abbiamo escluso quel proxy, con il ritorno indietro pronto.
- Risultato
- 9 macchine su 9 salvate in 38 minuti.
-
Gruppo industriale Consegnato
Crash notturni e una catena di job spezzata
- Il problema
- Il servizio di backup cadeva di notte (13 volte in 14 giorni) e una catena di job si era spezzata in silenzio, lasciando molte macchine senza copie recenti.
- Cosa abbiamo fatto
- Cause in fila: istanza SQL con nome, porta risolta via UDP, memoria sotto pressione, pacchetti scartati. I crash sono stati chiusi con una porta TCP statica; la catena è stata ricucita e i job più vecchi migrati per passare alla versione 13.
- Risultato
- Catena ripristinata; 48 job migrati alla versione 13, nessuno fallito.
Recupero dati dopo guasti
Quando un volume non monta o una macchina non riparte, prima mettiamo al sicuro una copia, poi lavoriamo solo su quella e verifichiamo il risultato fino al byte. La prima regola è non fare danni irreversibili cercando di riparare.
Tecnologie e prodotti
- ZFS (snapshot, clone, send e receive)
- refsutil ed esentutl
- LVM thin
- mdadm
- Veeam Extract
Esempi
-
Società di servizi Consegnato
Dieci terabyte da un volume illeggibile, verificati byte per byte
- Il problema
- Un repository di backup ReFS da 16 TiB era diventato illeggibile; sembrava un guasto dei dischi.
- Cosa abbiamo fatto
- Gli «errori di I/O» erano spazio esaurito nello storage sottostante, i dischi erano sani. Copia integrale su un altro nodo (15,6 TB, verificata). Su un clone abbiamo scoperto che Windows Server 2025 aggiorna il volume in modo irreversibile anche senza montarlo: sull’originale avrebbe bruciato l’unico strumento capace di leggerlo. L’estrazione si è fatta sul clone.
- Risultato
- 1.479 file e 10,08 TB estratti con verifica byte per byte in circa 3,5 giorni invece dei 20 stimati; database dei backup di Microsoft 365 riparati, backup ripartiti, danni residui sotto l‘1,6%.
-
Gruppo industriale Consegnato
Una macchina di produzione recuperata con 14 ms di fermo
- Il problema
- Una macchina virtuale di produzione stava su un pool thin corrotto.
- Cosa abbiamo fatto
- Recuperata da un clone dello snapshot dell’array su un nodo isolato, poi riportata nel cluster con una migrazione a caldo.
- Risultato
- 14 millisecondi di fermo; la bonifica del pool ha poi liberato circa 23 TiB.
-
Piccola impresa dopo un attacco ransomware Consegnato
I backup ritrovati su un disco uscito dal mirror
- Il problema
- Dopo un attacco servivano copie integre delle macchine virtuali.
- Cosa abbiamo fatto
- Un disco uscito mesi prima dal mirror del NAS conteneva una catena di backup integra: montato in sola lettura forzata e copiato sul nuovo NAS.
- Risultato
- 826 GB e 4 macchine virtuali recuperati.
Disaster recovery e repliche
Gestiamo repliche (Veeam, vSphere Replication, ZFS, sincrone fra array) e siti di disaster recovery; misuriamo l’RPO reale e scriviamo i runbook di spegnimento e riaccensione, con il punto oltre il quale da remoto non si torna indietro indicato chiaramente.
Tecnologie e prodotti
- Veeam Replication e vSphere Replication
- ZFS
- Dell PowerStore Metro
- IBM FlashSystem e NetApp ONTAP
- Cisco UCS Manager
- Redfish
Esempi
-
Gruppo manifatturiero Consegnato
Un sito di disaster recovery spento e riacceso tutto da remoto
- Il problema
- Il sito DR (storage virtualizzato, server blade, 6 host e circa 145 macchine di replica) doveva essere spento e poi riacceso senza nessuno sul posto.
- Cosa abbiamo fatto
- Piano di spegnimento in 10 fasi con uno script che di base simula soltanto, conferme esplicite per i passi che toccano la produzione e blocchi di sicurezza. Riaccensione con un orchestratore in 8 fasi; un controller dello storage fermo al loader è stato riavviato dalla console di gestione remota del server.
- Risultato
- Verifica con un accesso reale a 30 apparati: 30 su 30. Poi abbiamo misurato il vuoto di RPO accumulato (circa 3 giorni) e riattivato in catena i 26 job di replica.
-
Gruppo manifatturiero Consegnato
Repliche da una sede estera che fallivano sempre
- Il problema
- La replica da una sede estera falliva a ogni esecuzione.
- Cosa abbiamo fatto
- La causa era una catena di 9 snapshot mai consolidata sul lato di arrivo; repliche ricreate via API.
- Risultato
- Repliche di nuovo regolari.
Continuità operativa e ripartenza dopo un blackout
Prepariamo accessi di emergenza indipendenti dalla rete che cade, sentinelle sulla stabilità della corrente e runbook di ripartenza a ondate, attenti ai cluster con fencing. Diagnostichiamo anche i sistemi fault tolerant, leggendo i registri hardware dei server.
Tecnologie e prodotti
- Router 4G e 5G di gestione
- Dell iDRAC e HPE iLO (Redfish)
- VMware HA e DRS
- SUSE HA (Pacemaker, STONITH)
- SAP HANA System Replication
- Stratus everRun
Esempi
-
Azienda manifatturiera Consegnato
Ripartire dopo un blackout con la corrente che andava e veniva
- Il problema
- Uno stabilimento era senza corrente stabile; l’unico accesso rimasto era un router 4G/5G di gestione.
- Cosa abbiamo fatto
- Da lì una sentinella registrava cadute e ritorni della rete elettrica, con una regola semplice: non si accende nulla finché la rete non regge 30 minuti. I controller di gestione dei server dicevano quale sala aveva corrente. Runbook di ripartenza in 9 fasi, scritto per indirizzi IP perché a freddo il DNS non c’è.
- Risultato
- Alla ripartenza circa 90 macchine si erano accese su un solo host (RAM al 94%): 61 ridistribuite a caldo, 61 su 61 riuscite. Il database, passato sul nodo secondario, è stato analizzato e la procedura di riallineamento preparata, da eseguire su autorizzazione.
-
Cluster fault tolerant a due nodi Consegnato
Una scheda di rete che spariva dal bus
- Il problema
- Il cluster andava in crash periodicamente e, dopo il subentro, rispondeva una macchina su tre.
- Cosa abbiamo fatto
- Nei registri hardware letti via Redfish (208 voci, 48 critiche) comparivano sempre gli stessi tre errori PCIe: la scheda 10G di sincronizzazione spariva dal bus.
- Risultato
- Causa dimostrata e spiegato anche il comportamento dopo il subentro; raccomandazione consegnata.
Database e server applicativi
Lavoriamo su SQL Server, Oracle (anche in RAC, con ASM e RMAN), SAP HANA, PostgreSQL e MongoDB, e sui server applicativi Windows e Linux: MES, file server, collaborazione, web.
Tecnologie e prodotti
- SQL Server, dal 2016 al 2025
- Oracle RAC, ASM, RMAN
- SAP HANA
- PostgreSQL e MongoDB
- IIS, nginx, Docker
- Nextcloud e ONLYOFFICE
Esempi
-
Gestionale aziendale su SQL Server Consegnato
Una transazione da 132 byte che riempiva il disco
- Il problema
- Il log del database arrivava a 267-275 GB e riempiva il disco.
- Cosa abbiamo fatto
- La causa era un’applicazione esterna che lasciava aperta una transazione di sola lettura da 132 byte: anche in recovery SIMPLE bastava a impedire il riciclo del log. Rimedio d’emergenza e un tetto al log.
- Risultato
- Disco al sicuro; la correzione dell’applicazione è stata indicata a chi la sviluppa.
-
Oracle in RAC Consegnato
RMAN bloccato da archivelog cancellati a mano
- Il problema
- I backup RMAN non partivano più dopo che alcuni archivelog erano stati cancellati a mano.
- Cosa abbiamo fatto
- Rimossi 22.527 record orfani dal controlfile, catalogo registrato di nuovo, 11 sessioni bloccate terminate.
- Risultato
- Backup di prova riuscito e procedure di arresto e riavvio scritte.
-
File server aziendale Consegnato
Sette milioni di permessi letti in otto minuti
- Il problema
- Serviva sapere chi può leggere che cosa su un file server cresciuto negli anni.
- Cosa abbiamo fatto
- Uno scanner dei permessi NTFS scritto apposta.
- Risultato
- 465.280 cartelle e 7,3 milioni di permessi analizzati in meno di 8 minuti.
Posta, Exchange e Microsoft 365
Gestiamo Exchange on-premise, gateway di posta di frontiera, tenant Microsoft 365 via PowerShell e Microsoft Graph, i backup di Microsoft 365 e le comunicazioni tecniche ai clienti quando un servizio cambia.
Tecnologie e prodotti
- Exchange Server 2019 e SE
- Exchange Online PowerShell
- Microsoft Graph ed Entra ID
- Veeam Backup for Microsoft 365
- Postfix
Esempi
-
Clienti con backup di Microsoft 365 Consegnato
Il ritiro di EWS in Exchange Online, spiegato ai clienti
- Il problema
- Il ritiro di Exchange Web Services in Exchange Online rischiava di fermare i backup di Microsoft 365.
- Cosa abbiamo fatto
- Una guida per i clienti (impostazioni del tenant, tempi di propagazione, aggiornamenti) e lo script per applicare le impostazioni.
- Risultato
- Una guida e uno script che ogni cliente può applicare da sé.
-
Gruppo industriale Consegnato
Un gateway di posta rifatto accanto al vecchio
- Il problema
- Il server di posta di frontiera girava su un sistema operativo fuori supporto.
- Cosa abbiamo fatto
- Il nuovo server è stato costruito accanto al vecchio e la catena SMTP provata prima dello scambio di indirizzo.
- Risultato
- Nuovo server in servizio, con il vecchio tenuto pronto come ritorno.
Cloud pubblico e server dedicati
Su Google Cloud gestiamo Compute Engine, reti VPC, Cloud VPN, Cloud SQL, snapshot, Monitoring, Logging e registri di audit. Sui server dedicati installiamo e gestiamo macchine via API del provider, reti private, blocchi di indirizzi e rinnovi.
Tecnologie e prodotti
- Google Cloud (Compute Engine, Cloud VPN, Cloud SQL, Ops Agent, IAM)
- Server dedicati e cloud pubblico OVHcloud
- API dei provider
Esempi
-
Infrastruttura su Google Cloud di un servizio pubblico In esercizio
Una macchina che rifiutava SSH, e non era la memoria
- Il problema
- Una macchina virtuale rifiutava le connessioni di amministrazione e sembrava a corto di memoria.
- Cosa abbiamo fatto
- 151 apparati si collegavano di continuo (circa 53 connessioni al minuto) e, con la macchina rallentata, saturavano le connessioni non ancora autenticate; la causa di fondo erano 16 processi Java senza limite di memoria. I log, misurati in 151,9 GiB in 30 giorni, sono stati ridotti tenendo le metriche.
- Risultato
- Causa chiarita e carico ridotto; una rete aggiunta alla VPN con runbook e ritorno indietro, con 2 minuti e 54 secondi di fermo e verifica da tre reti diverse.
-
Infrastruttura su Google Cloud di un servizio pubblico In esercizio
La copia pesante di mezzogiorno era un fuso orario
- Il problema
- I backup con agent delle macchine Linux fallivano e una copia pesante partiva in pieno giorno.
- Cosa abbiamo fatto
- Secure Boot bloccava il modulo del kernel usato per gli snapshot: i job sono stati rifatti senza snapshot. La copia di mezzogiorno era il fuso orario sbagliato dei server di backup.
- Risultato
- Nove macchine salvate con regolarità, negli orari giusti.
Prestazioni, capacità e monitoraggio
Misuriamo prima di dimensionare e costruiamo portali e sonde di monitoraggio che distinguono «sano», «non verificato» e «guasto», con soglie tarate sullo storico e allarmi per episodi, non per singole letture.
Tecnologie e prodotti
- Python (FastAPI, SQLite)
- nginx e systemd
- SNMP
- Redfish, WinRM e PowerShell
- PSI di Linux
- Notifiche via Telegram
Esempi
-
Fornitore di servizi informatici In esercizio
Da 250 notifiche al giorno a zero, tenendo gli allarmi veri
- Il problema
- Un monitoraggio di 36 nodi in 8 gruppi produceva allarmi perenni e centinaia di notifiche di oscillazione.
- Cosa abbiamo fatto
- Archivio su due livelli (dati grezzi per 7 giorni, aggregati orari per 400), soglie tarate sullo storico, un ritardo di conferma prima di notificare. Un controllo sull’età dell’ultimo backup, letta dal database invece che dal job.
- Risultato
- Da 5 allarmi, 3 perenni, a 2 veri; notifiche di oscillazione da circa 250 al giorno a zero; un grafico di 30 giorni si apre in circa 25 ms. Il controllo sui backup ha trovato database senza una copia completa recente mentre il job risultava riuscito.
-
Grande evento culturale internazionale Consegnato
La parete di monitoraggio di un grande evento
- Il problema
- Tenere sotto controllo apparati, linee e Wi-Fi di una rete temporanea, con una vista leggibile da lontano in sala regia.
- Cosa abbiamo fatto
- Portale in Python senza framework né database esterni: 20 apparati controllati ogni 60 secondi, banda ed errori ogni 10, radio e client degli access point ogni 45; parete con colori solo semantici, verificata con screenshot; avvisi su Telegram. La regola d’allarme a episodi è stata validata rigiocando 24 ore di dati reali.
- Risultato
- Notifiche da circa 80 a 4 al giorno. Sono emersi anche un resolver DNS che impiegava 3-4 secondi per nome e gli access point spinti dai radar meteorologici su canali a potenza ridotta, riportabili a 1 W con un pulsante.
-
Piattaforma su server dedicato Studio
La CPU nuova non serviva
- Il problema
- Capire se un nodo andava potenziato.
- Cosa abbiamo fatto
- Misure di carico reali: in media 0,41 core su 24. Misurato anche il costo della cifratura del disco: circa l‘1,5% di un core nei picchi.
- Dove siamo arrivati
- Il limite era il disco, non la CPU: lo studio indica dove conviene intervenire.