Vai al contenuto
Strategia Informatica
  1. Inizio
  2. Competenze
  3. 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

  1. 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.
  2. 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

  1. 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.
  2. 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

  1. 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.
  2. 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

  1. 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.
  2. 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.
  3. 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

  1. 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.
  2. 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.
  3. 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

  1. 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%.
  2. 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.
  3. 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

  1. 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.
  2. 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

  1. 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.
  2. 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

  1. 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.
  2. 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.
  3. 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

  1. 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é.
  2. 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

  1. 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.
  2. 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

  1. 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.
  2. 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.
  3. 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.

Raccontateci il problema

Una rete da rimettere in ordine, un incidente da gestire, dati da far parlare: la prima conversazione serve a capire se e come possiamo essere utili.