Backup del database: Tipi, metodi e best practice

Il backup dei database è il processo di creazione di copie ripristinabili dei dati, della struttura e della configurazione dei database per proteggerli da perdita, danneggiamento o distruzione non autorizzata. Per le organizzazioni che dipendono dai database per eseguire transazioni, servire i clienti e archiviare record business-critical, un backup non riuscito o mancante può comportare ore di downtime e milioni di perdite di fatturato.

Secondo un sondaggio ITIC del 2024, il 41% delle aziende stima che un'ora di downtime possa costare da 1 milione a oltre 5 milioni di dollari. Ransomware aumenta il rischio: Il "Report sulle indagini sulle violazioni dei dati 2025" di Verizon ha rilevato la Ransomware presenza di ransomware nel 44% delle violazioni analizzate, con un aumento del 37% rispetto all'anno precedente.

Una strategia di backup dei database ben progettata riduce l'esposizione a tutte queste minacce. Questo articolo descrive come funziona il backup dei database, i principali tipi di backup, come pianificare una strategia per gli obiettivi di ripristino e le best practice che separano la data protection affidabile da costose lacune.

Come funziona il backup dei database

In sostanza, il backup del database acquisisce una copia point-in-time dei dati e li memorizza separatamente dall'ambiente di produzione. Il processo prevede la lettura dei file di database, come file di dati, registri delle transazioni e metadati di configurazione, e la loro scrittura in una posizione di destinazione come un disco locale, un dispositivo NAS (Network Attached Storage), una Storage Area Network (SAN) o un cloud object storage.

La maggior parte dei sistemi di gestione dei database (DBMS) fornisce utilità di backup native. SQL Server utilizza il comando BACKUP DATABASE. PostGreSQL si basa su pg_dump per le esportazioni logiche e pg_basebackup per le copie fisiche. Oracle utilizza Recovery Manager (RMAN) e MySQL offre mysqldump insieme allo strumento MySQL Enterprise Backup per i backup fisici.

Il processo di backup può essere eseguito online ("hot") mentre il database esegue query in tempo reale o offline ("freddo") con il database spento. Gli hot backup sono standard per gli ambienti di produzione che richiedono disponibilità continua. I backup a freddo sono più semplici e talvolta più veloci, ma forzano il downtime, rendendoli impraticabili per i sistemi con contratti di servizio (SLA) limitati.

Indipendentemente dal metodo, ogni backup deve essere archiviato separatamente dal database di produzione. Se un guasto del disco, un attacco Ransomware o un'eliminazione accidentale distruggono i dati primari, un backup memorizzato sullo stesso sistema di storage non fornisce alcuna protezione.

Tipi di backup del database

La scelta del tipo di backup corretto dipende dalle dimensioni del database, dalla frequenza di modifica dei dati, dalla tolleranza alla perdita di dati e dalla velocità di ripristino. La maggior parte degli ambienti aziendali combina più tipi in una rotazione pianificata.

Backup completo

Un backup completo crea una copia completa dell'intero database, inclusi tutti i file di dati, gli oggetti schema e le procedure memorizzate. Fornisce il percorso di ripristino più semplice, basta eseguire il restore del singolo set di backup, ma consuma anche la maggior parte dello storage e richiede il tempo più lungo per essere completato. I backup completi servono in genere come base per le strategie incrementali e differenziali.

Backup incrementale

Un backup incrementale acquisisce solo i dati modificati dall'ultimo backup di qualsiasi tipo (completo o incrementale). Questo approccio utilizza meno storage e termina più velocemente di un backup completo. Il compromesso: Il ripristino richiede l'ultimo backup completo più ogni backup incrementale nella catena, in sequenza. Se un collegamento in quella catena è danneggiato, il restore non riesce.

Backup differenziale

Un backup differenziale registra tutte le modifiche dall'ultimo backup completo, indipendentemente dai backup intermedi. Raggiunge un punto di partenza tra pieno e incrementale: Richiede più storage che incrementale, ma semplifica il ripristino perché serve solo l'ultimo backup completo più il differenziale più recente. Molte organizzazioni pianificano backup completi settimanali con differenziali giornalieri.

Backup fisici e logici

I backup fisici copiano i file di database raw a livello di file system o blocco. Sono veloci da creare e ripristinare, il che li rende lo standard per i database su larga scala. I backup logici esportano il database come istruzioni SQL (CREATE TABLE, INSERT) o dump strutturati. Sono più portatili tra diverse versioni di database o piattaforme, ma sono più lenti da eseguire e ripristinare. Una strategia solida spesso utilizza backup fisici per il ripristino quotidiano e backup logici per l'archiviazione a lungo termine o la migrazione tra piattaforme.

Backup del database e replica del database

Il backup e la replica hanno scopi diversi, ma spesso sono confusi. La replica mantiene una copia sincronizzata del database su un server separato, in genere per l'alta disponibilità e la scalabilità in lettura. Se il server primario si guasta, la replica può assumere il controllo quasi immediatamente.

Ma la replica non è un backup. Una tabella danneggiata, un comando DROP DATABASE accidentale o un evento di crittografia Ransomware si replicano in standby alla stessa velocità delle modifiche legittime. La replica protegge dai guasti hardware. Il backup protegge dalla perdita di dati. Gli ambienti aziendali hanno bisogno di entrambi.

RTO e RPO: Pianificazione della strategia di backup del database

Due metriche sono alla base di ogni strategia di backup: Recovery Time Objective (RTO) e Recovery Point Objective (RPO).

L'RTO definisce il tempo massimo accettabile per il restore di un database e il ripristino delle operazioni dopo un guasto. L'RPO definisce la quantità massima accettabile di perdita di dati, misurata nel tempo. Un RPO di un'ora significa che puoi tollerare di perdere fino a un'ora di transazioni.

Queste due metriche dovrebbero guidare ogni decisione sulla frequenza, il tipo e la posizione di storage del backup:

• Un RPO prossimo allo zero richiede backup continui dei registri delle transazioni o snapshot a livello di storage eseguiti ogni pochi minuti.
• Un RTO di quattro ore può essere raggiungibile con restore standard basati su disco, mentre un RTO inferiore a un'ora richiede in genere repliche pre-stadiate o tecnologia di ripristino istantaneo.
• I vincoli di budget e infrastruttura determinano ciò che è realistico. Un RPO pari a zero è tecnicamente raggiungibile con la replica sincrona, ma l'impatto su costi e latenza potrebbe non giustificarlo per ogni workload.

Inizia classificando i database in tier in base alla criticità aziendale, quindi assegna gli obiettivi RTO e RPO a ciascun tier. Non tutti i database garantiscono lo stesso livello di protezione, ma ogni database ha bisogno di un piano.

La regola del backup 3-2-1-1-0

La regola di backup 3-2-1 tradizionale, ovvero tre copie di dati, su due diversi tipi di supporti, con una copia offsite, è stata lo standard di riferimento per anni. Il fotografo Peter Krogh lo ha reso popolare nel 2009, quando il nastro era ancora un obiettivo primario per il backup e il Ransomware non era un problema diffuso.

La moderna regola 3-2-1-1-0 estende questo framework con due aggiunte create per il panorama delle minacce di oggi:

• 3 copie dei dati (l'originale più almeno due backup)
• 2 diversi tipi di supporti (ad esempio, storage a oggetti su disco e cloud)
• 1 copia fuori sede (separata geograficamente dal data center primario)
• 1 copia offline o immutabile (storage air-gapped o write-once che il Ransomware non può crittografare o eliminare)
• 0 errori (verificati tramite test di restore periodici, in modo da sapere che i backup funzionano effettivamente)

L'elemento "1 immutabile" è l'aggiornamento critico. Gli attacchi moderni colpiscono in modo specifico i repository di backup per eliminare le opzioni di ripristino prima di crittografare i dati di produzione.

Best practice per il backup dei database

Automatizza e pianifica in modo coerente

I backup manuali non sono affidabili. Usa gli strumenti di pianificazione integrati nel tuo DBMS (SQL Server Agent, processi cron con pg_dump, pianificazione RMAN) o una piattaforma di backup centralizzata per applicare una pianificazione coerente. Un modello comune: backup completi settimanali con differenziali giornalieri e backup dei registri delle transazioni ogni 15-30 minuti.

Il test viene eseguito regolarmente

Un backup che non hai mai ripristinato è un backup di cui non puoi fidarti. Pianifica i test di restore trimestrali almeno una volta al mese per i database mission-critical. Esegui il restore in un ambiente separato, verifica l'integrità dei dati e documenta il tempo di ripristino effettivo rispetto agli obiettivi RTO.

Crittografia dei backup in modalità REST e in transito

I backup dei database contengono gli stessi dati sensibili dei sistemi di produzione. Applica la crittografia AES-256 ai file di backup a REST e utilizza TLS per tutti i dati di backup che si spostano in una rete. La crittografia è spesso un requisito di conformità ai sensi di normative come HIPAA, GDPR e PCI DSS.

Monitoraggio e avviso dei guasti

I processi di backup falliscono in silenzio più spesso di quanto la maggior parte dei team si renda conto. Configura il monitoraggio che segnala l'assenza di finestre di backup, i processi non riusciti o le modifiche impreviste delle dimensioni del backup. Un calo improvviso delle dimensioni del backup potrebbe indicare una perdita di dati che non è ancora stata rilevata.

Definire e applicare le policy di conservazione

Le policy di conservazione determinano per quanto tempo le copie di backup vengono conservate prima di essere riciclate o eliminate. La giusta finestra di conservazione dipende dai requisiti di conformità, dalla capacità di storage e dall'orizzonte temporale in cui potrebbe essere necessario eseguire il ripristino da un problema non rilevato. Molte organizzazioni conservano i backup giornalieri per 30 giorni, i backup settimanali per 90 giorni e i backup mensili per un anno.

Separa lo storage di backup dalla produzione

Archivia i backup su un'infrastruttura fisicamente e logicamente separata dallo storage di produzione. Ciò significa array di storage, segmenti di rete e posizioni geografiche idealmente diverse. Se il Ransomware crittografa lo storage di produzione e il backup risiede nella stessa rete SAN, entrambi sono compromessi.

Problemi comuni di backup dei database

Anche le strategie di backup ben pianificate incontrano ostacoli pratici. Comprendere queste sfide in anticipo ti aiuta a progettare in base a esse.

• Le grandi dimensioni dei database estendono le finestre di backup. I database con più terabyte possono richiedere ore di backup, soprattutto con i backup completi tradizionali su storage di rete. I backup incrementali a livello di blocco, le snapshot a livello di storage e i canali di backup paralleli aiutano a comprimere la finestra di backup.
• La proliferazione del backup aumenta i costi. Senza policy di conservazione chiare e deduplica, i costi dello storage di backup aumentano più velocemente rispetto ai dati di produzione. La deduplica e la compressione, combinate con lo storage a più livelli (backup a caldo su disco veloce, backup invecchiati su object storage più economico), aiutano a controllare la spesa.
• Gli ambienti multidatabase aumentano la complessità. La maggior parte delle aziende esegue un mix di SQL Server, Oracle, PostGreSQL, MySQL e sempre più sistemi NoSQL come MongoDB. Ognuno ha i propri strumenti di backup e procedure di restore. Una piattaforma di backup centralizzata che supporta più motori di database semplifica le operazioni e riduce il rischio di lacune.
• I database cloud-native richiedono approcci diversi. I servizi gestiti come Amazon RDS, Azure SQL Database e Google Cloud SQL gestiscono i backup automatizzati, ma le organizzazioni devono ancora comprendere le finestre di conservazione predefinite, le opzioni di replica tra regioni e come eseguire il ripristino in un determinato momento. È una supervisione comune affidarsi interamente alle impostazioni predefinite dei provider senza personalizzare le impostazioni di RPO e conservazione.

Il futuro del backup dei database

Il backup dei database sta passando da operazioni pianificate e basate sul lavoro a una protezione continua e integrata nello storage. La data protection continua (CDP) acquisisce ogni modifica al database in tempo reale, consentendo il Point-in-Time Recovery in qualsiasi secondo, non solo l'ultima finestra di backup pianificata.

Anche le snapshot native per lo storage stanno cambiando i vantaggi economici del backup. Invece di copiare interi set di dati, la tecnologia snapshot acquisisce solo i blocchi modificati, completandoli in pochi secondi, indipendentemente dalle dimensioni del database. Insieme a policy di snapshot immutabili, questo approccio offre un RPO quasi pari a zero con protezione Ransomware integrata.

Il rilevamento delle anomalie basato sull'AI sta emergendo come un altro livello di difesa. Analizzando i modelli di metadati di backup, come dimensioni, durata e velocità di modifica, questi sistemi possono segnalare le attività insolite (come un evento di crittografia Ransomware) prima di propagarsi alle copie di backup.

Conclusione

Il backup dei database è l'ultima linea di difesa tra l'organizzazione e la perdita permanente di dati. Una solida strategia di backup, basata sulla giusta combinazione di backup completi, incrementali e differenziali, allineata a target RTO e RPO definiti e rafforzata con il framework 3-2-1-1-0, trasforma il backup da un'attività IT di routine in una vera e propria funzionalità di business continuity.

Il costo per sbagliare è misurato in ore di downtime, perdita di fatturato ed esposizione normativa. Il costo di una soluzione corretta è una frazione di quello di un singolo incidente irrecuperabile.

Everpure™ FlashArray™ e FlashBlade® offrono snapshot native per lo storage che si completano in pochi secondi senza alcun impatto sulle performance, indipendentemente dalle dimensioni dei dataset. Insieme a Everpure SafeMode™ Snapshots, che creano copie immutabili che non possono essere eliminate o modificate da alcun utente, amministratore o utente malintenzionato, le organizzazioni ottengono un'architettura di backup creata sia per la velocità che per la resilienza del Ransomware. Insieme allo storage as a service Evergreen//One™, i team possono scalare la capacità di backup senza investimenti iniziali nell'infrastruttura.