---
title: "Backup eterogeneo: come proteggere ambienti IT misti senza creare lacune nel processo di ripristino"
published_at: "2026-10-02T15:18:35+00:00"
modified_at: "2026-10-02T15:18:50+00:00"
url: "https://www.baculasystems.com/it/it-blog/backup-eterogeneo/"
markdown_url: "https://www.baculasystems.com/it/it-blog/backup-eterogeneo.md"
---

[Principale](https://www.baculasystems.com/it/)
 > [Blog sul backup e sul ripristino](https://www.baculasystems.com/it/it-blog/)
 > Backup eterogeneo: come proteggere ambienti IT misti senza creare lacune nel processo di ripristino

# Backup eterogeneo: come proteggere ambienti IT misti senza creare lacune nel processo di ripristino

Aggiornato 2nd Ottobre 2026, Rob Morrison

## Che cos’è il backup eterogeneo?

Il backup eterogeneo è una strategia che protegge diversi tipi di carichi di lavoro, tra cui server fisici, macchine virtuali, database, Kubernetes, applicazioni SaaS e carichi di lavoro cloud, nell’ambito di politiche di ripristino comuni. Le destinazioni di ripristino comuni non richiedono metodi di backup identici.

Un backup riuscito non garantisce un ripristino riuscito. Il backup eterogeneo protegge diversi tipi di carichi di lavoro nell’ambito di obiettivi di ripristino comuni. Molti ambienti IT aziendali combinano più sistemi operativi, hypervisor, database, servizi cloud e piattaforme legacy. Nello specifico, è possibile imbattersi in aziende che gestiscono le proprie operazioni su server Windows e Linux e utilizzano macchine virtuali VMware e Hyper-V. Inoltre, queste aziende possono utilizzare contemporaneamente cluster Kubernetes, carichi di lavoro nel cloud pubblico, applicazioni Software-as-a-Service (SaaS), database, sistemi di archiviazione collegati in rete e piattaforme fisiche o Unix meno recenti, come i mainframe IBM System z (z/OS) e IBM AIX su Power Systems (o Oracle Solaris / HP-UX).

Gli ambienti misti possono derivare da acquisizioni, migrazioni al cloud, modernizzazione delle applicazioni, mantenimento di sistemi legacy e acquisti tecnologici decentralizzati. Pertanto, la sfida principale in materia di backup consiste nel garantire un ripristino affidabile tra sistemi associati a diverse interfacce di elaborazione delle applicazioni (API), meccanismi di coerenza, identità, metadati e modalità di guasto. Un’API rappresenta un insieme di regole che consentono a due componenti software di comunicare sulla base di una serie di definizioni e protocolli.

Una strategia di **backup eterogeneo** utilizza un’architettura coordinata di protezione dei dati per proteggere più sistemi operativi, applicazioni, database, hypervisor, piattaforme di storage e ambienti cloud.

La strategia di backup eterogenea mira a stabilire risultati di ripristino comuni, quali [gli obiettivi di punto di ripristino (RPO)](https://blog.bcm-institute.org/it-disaster-recovery/recovery-time-and-point-objectives)
, [gli obiettivi di tempo di ripristino (RTO)](https://docs.oracle.com/en-us/iaas/mysql-database/doc/recovery-time-objective-rto-and-recovery-point-objective-rpo.html)
, la conservazione, l’immutabilità, il controllo degli accessi e i test. I test di ripristino fanno parte della progettazione del backup.

L’RPO è la quantità massima accettabile di perdita di dati che un’organizzazione può tollerare prima che l’attività ne risenta. L’RTO è il periodo massimo durante il quale un’azienda può rimanere inattiva prima che l’interruzione causi un impatto inaccettabile.

I database, le macchine virtuali e le applicazioni Kubernetes possono condividere un RPO pur utilizzando meccanismi di protezione diversi. È essenziale standardizzare gli obiettivi di ripristino anziché costringere ogni carico di lavoro a seguire lo stesso processo di backup.

Allo stesso tempo, la strategia contribuisce a preservare i metodi specifici per ciascun carico di lavoro, come i carichi di lavoro dei database e le macchine virtuali, necessari per raggiungerli.

È importante sottolineare che, se tutti i processi su una dashboard sono verdi, ciò non indica che un’azienda sia in grado di ripristinare le proprie applicazioni. Un backup eterogeneo efficace standardizza le politiche e le procedure, rispettando le differenze tecniche, come i backup di database coerenti con l’applicazione con log delle transazioni per il ripristino a un punto nel tempo e i backup di immagini a livello di hypervisor per il ripristino completo delle macchine virtuali.

## Cosa rende eterogeneo un ambiente di backup?

Un ambiente di backup è eterogeneo quando i suoi carichi di lavoro richiedono metodi di backup o ripristino diversi e sono soggetti a metodi di ripristino diversi. Gli ambienti IT misti richiedono metodi di backup specifici per ogni carico di lavoro.

Un ambiente misto può includere:

- macOS, server Unix, Linux, Windows fisico
- Macchine virtuali Proxmox, VMware, Nutanix, Hyper-V, macchine virtuali basate sul kernel
- Volumi persistenti, cluster Kubernetes, manifesti, segreti e metadati delle applicazioni
- Database (ad es. Microsoft SQL Server, Oracle, PostgreSQL, MySQL, SAP HANA, MongoDB)
- Ad esempio, dispositivi NAS e file system
- Ad esempio, cloud privato e carichi di lavoro meno comuni o tecnicamente complessi
- Ad esempio, Salesforce e Microsoft 365
- Mainframe, applicazioni proprietarie o sistemi che non supportano un agente moderno

L’infrastruttura rappresenta un livello. Esistono diversi requisiti di ripristino. Un database transazionale potrebbe subire una perdita di dati. Tuttavia, un archivio potrebbe consentire un [obiettivo di punto di ripristino (RPO)](https://csrc.nist.gov/glossary/term/rpo)
 di 24 ore. L’RPO rappresenta il momento nel tempo fino al quale i dati devono essere ripristinati dopo un’interruzione.

Per i sistemi di [produzione](https://www.baculasystems.com/it/sicurezza-informatica-industriale/)
 che devono continuare a funzionare durante le interruzioni della WAN, potrebbe essere necessaria un’infrastruttura di ripristino locale anche quando la [rete geografica (WAN)](https://aws.amazon.com/what-is/wan/)
 non è disponibile. Una rete geografica è la tecnologia che collega uffici, data center, applicazioni cloud e archiviazione cloud.

I periodi di conservazione dipendono dalla giurisdizione applicabile, dal tipo di documento, dal contratto e dal regime normativo. E per un ambiente di sviluppo di breve durata potrebbero essere necessari solo pochi punti di ripristino.

Ecco perché «supporta molte piattaforme» è una definizione incompleta di backup eterogeneo. Una piattaforma può acquisire dati da molte fonti. Il ripristino coerente con l’applicazione non è tipico di tutte le fonti. Lo stesso vale anche per il ripristino multipiattaforma testato, il ripristino della configurazione o il ripristino granulare.

## Perché carichi di lavoro diversi richiedono metodi di backup diversi?

Carichi di lavoro diversi richiedono meccanismi di backup diversi perché raggiungono uno stato recuperabile in modi diversi. È utile standardizzare i diversi carichi di lavoro, ma esistono rischi nascosti associati a un’uniformità letterale. Le classi di carico di lavoro raggiungono uno stato recuperabile in vari modi.

Uno snapshot dell’hypervisor può fornire la base per il backup di una macchina virtuale (VM) quando il prodotto di backup acquisisce anche la configurazione e lo stato richiesto dell’applicazione. Per un database potrebbero essere necessari un’API di backup nativa, i log delle transazioni e il coordinamento del troncamento dei log. Un’applicazione Kubernetes potrebbe necessitare di dati persistenti e manifest, risorse personalizzate, segreti e informazioni sulle dipendenze.

Una piattaforma Software-as-a-Service (SaaS) espone solo gli oggetti e le [interfacce di programmazione delle applicazioni (API)](https://www.ibm.com/think/topics/api)
 consentiti dal proprio fornitore. Un’API rappresenta regole e protocolli, consentendo a diversi programmi software di comunicare tra loro. Per un server fisico potrebbero essere necessari file, stato del sistema e dati di ripristino bare-metal.

I carichi di lavoro che dispongono di uno snapshot giornaliero e di una politica di conservazione di 30 giorni presentano una configurazione coerente. Tuttavia, non garantiscono necessariamente la recuperabilità. Il sistema può continuare a funzionare senza dipendenze esterne, quali le dipendenze delle applicazioni Kubernetes, la configurazione delle identità e le chiavi di crittografia. Ciò si riferisce anche alla configurazione delle identità o ai metadati cloud-native. Inoltre, il sistema potrebbe non essere ripristinabile in una regione, un cluster, un hypervisor o un account diversi.

I carichi di lavoro che appartengono allo stesso livello aziendale dovrebbero raggiungere lo stesso risultato previsto, anche se dispongono di meccanismi di backup diversi. Ad esempio, una politica di Livello 1 potrebbe richiedere (il Livello 1 è una classificazione illustrativa, non una definizione universale del settore):

- Massimo 15 minuti di perdita di dati
- Ripristino del servizio entro due ore
- Una copia immutabile che non si trovi all’interno dei confini di sicurezza della produzione
- Test di ripristino da eseguire trimestralmente
- Prove che dimostrino che il ripristino delle dipendenze delle applicazioni sia stato effettuato correttamente. Tali dipendenze possono includere dipendenze relative all’ordine di ripristino, nonché infrastrutture a monte e servizi di sicurezza.

Un database Oracle o un’applicazione Kubernetes possono utilizzare strumenti o plug-in diversi per conformarsi a tale politica. Tali strumenti o plug-in possono includere Oracle Recovery Manager e il plug-in Dell PowerProtect Data Manager. Il controllo segue un percorso standardizzato. L’implementazione è ottimizzata per il carico di lavoro.

## In che modo i team dovrebbero mappare i carichi di lavoro al metodo di protezione corretto?

Un progetto di backup eterogeneo dovrebbe basarsi su un inventario orientato al ripristino, anziché su un elenco di dispositivi. Di norma, gli inventari dell’infrastruttura identificano gli host e la capacità di archiviazione senza illustrare gli elementi di un servizio aziendale completo.

Iniziare mappando le applicazioni alle loro dipendenze relative a risorse di calcolo, dati, configurazione, identità, rete, certificati e servizi esterni, quali gateway di pagamento/API di terze parti, database gestiti esternamente o provider di identità SaaS.

Successivamente, classificarle tenendo conto del loro impatto sul business. Infine, definire il loro Recovery Point Objective (RPO) e Recovery Time Objective (RTO), nonché i tempi di conservazione.

Inoltre, definite i relativi requisiti legali, quali le leggi sulla sovranità e la residenza dei dati (ad es. il Regolamento generale sulla protezione dei dati) e gli standard di conservazione obbligatori (ad es. [Health Insurance Portability and Accountability Act](https://www.hhs.gov/hipaa/index.html)
), la sede di ripristino e il responsabile.

Il [GDPR](https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/principles-gdpr_en)
 è la normativa europea in materia di privacy e sicurezza dei dati. L’[HIPAA](https://www.hhs.gov/hipaa/for-professionals/faq/does-hipaa-require-covered-entities-to-keep-medical-records-for-any-period/index.html)
 stabilisce standard rigorosi per la gestione, la trasmissione e l’archiviazione delle informazioni sanitarie protette.

Valutate la possibilità di utilizzare questa tabella come punto di partenza:

| Tipo di carico di lavoro | Cosa proteggere | Metodo di coerenza preferito | Verifica del ripristino |
| --- | --- | --- | --- |
| Server fisico | Stato del sistema, file, dati di avvio, dati delle applicazioni | Integrazione tra agente e applicazione | Test di avvio bare-metal o su hardware alternativo |
| Macchina virtuale | Configurazione, dischi della VM, stato dell’applicazione | Snapshot dell’hypervisor più sospensione dell’applicazione | Avvio della VM isolata e test dei servizi |
| Database | Log, file di dati, configurazione, materiale di crittografia | API nativa del database o plug-in certificato | Ripristino, roll forward e controllo dell’integrità del database |
| Applicazione Kubernetes | Metadati del cluster/dell’applicazione e volumi persistenti | Hook dell’applicazione, snapshot dell’interfaccia di archiviazione dei container (CSI) e rilevamento compatibile con Kubernetes | Utilizzo di un namespace o cluster pulito per il ripristino e il test delle dipendenze |
| Archiviazione collegata alla rete (NAS) o piattaforma di file | Autorizzazioni, condivisioni, elenchi di controllo degli accessi (ACL) e metadati dei file | Backup a livello di file o integrazione di snapshot/API | Test di ripristino di autorizzazioni, file e directory di grandi dimensioni |
| Servizio cloud modernizzato | Configurazione della gestione delle identità e degli accessi (IAM), dati del servizio, identità e riferimenti, nonché contesto di regione/account | API del provider più copia indipendente, ove supportata | Ripristino su un account o una regione approvati |
| Applicazione SaaS | Autorizzazioni, oggetti, allegati e relazioni esposte dall’API | Connettore specifico per SaaS | Ripristino granulare degli oggetti e verifica delle relazioni |

È importante sottolineare che non tutte le dipendenze sono oggetti di backup. I seguenti elementi, che rientrano nel piano di ripristino, potrebbero richiedere procedure separate di protezione o ricreazione:

- Voci del sistema dei nomi di dominio (DNS), quali record A o AAAA e record di nomi canonici
- Repository “Infrastructure-as-code”, ad esempio repository GitLab/GitHub (contenenti script Terraform o Pulumi) e repository di modelli CloudFormation di Amazon Web Services
- Configurazione dei provider di identità
- Immagini dei container
- Server di licenze, come FlexNet Publisher (FlexLM) e Microsoft Key Management Services (KMS) Server
- Credenziali API di terze parti, come segreti client OAuth / token di aggiornamento e chiavi API dei gateway di pagamento

## Un processo passo dopo passo per la progettazione di un backup eterogeneo

### 1. Individuare i carichi di lavoro e assegnarne la proprietà

Integrare il rilevamento automatico con colloqui con i responsabili delle applicazioni, come le scansioni di rilevamento dell’infrastruttura (ad es. ServiceNow Discovery, Device42), questionari e colloqui sulla continuità operativa.

Identificare i sistemi non gestiti, come i server IT non autorizzati (Rogue/Shadow IT) e le macchine virtuali (VM) di sandbox o staging degli sviluppatori, nonché gli account cloud, come gli account di abbonamento ad hoc di AWS/Azure e gli spazi di lavoro dei progetti su Google Cloud Platform (GCP).

Inoltre, identificare i namespace di Kubernetes, come quelli di staging e dei rami di funzionalità (ad es., staging-checkout, dev-payments) e i siti remoti, quali filiali/depositi regionali e siti di produzione/elaborazione edge.

Identificare inoltre le applicazioni SaaS, quali le piattaforme di collaborazione aziendale (ad es. Microsoft 365, Google Workspace) e le piattaforme ereditate, quali i mainframe legacy/sistemi AS400 e gli ambienti IT delle controllate acquisite.

Assegnare un responsabile tecnico e un responsabile di business per ciascun servizio protetto.

### 2. Definire i livelli di ripristino prima di selezionare la tecnologia

Raggruppare i servizi in base all’impatto sul business. Assegnare requisiti misurabili relativi a RPO, RTO, conservazione, sede di ripristino e test, quali esecuzioni automatizzate trimestrali in ambiente sandbox di ripristino e simulazioni semestrali di failover completo.

Non lasciare che la pianificazione predefinita di uno strumento diventi il requisito aziendale.

### 3. Identificare i dati e i componenti di ciascun carico di lavoro che devono essere acquisiti insieme per creare un punto di ripristino utilizzabile

Decidete cosa dovreste acquisire per ottenere un punto di ripristino utilizzabile. Ad esempio, valutate l’acquisizione di file di dati e log per un database.

Valutate l’acquisizione di macchine virtuali, database, code di messaggi o risorse Kubernetes per un’applicazione multilivello. Registrate gli hook delle applicazioni, come quelli di congelamento pre-snapshot e di sblocco post-snapshot, nonché i requisiti di sequenziamento, quali le dipendenze di avvio ordinate (Infrastruttura – Database – Applicazione – Frontend).

### 4. Adattare i metodi di protezione al comportamento del carico di lavoro

Optare per una protezione basata su agente, senza agente, basata su snapshot, basata su API, nativa del database o continua. A tal fine, è necessario tenere conto delle esigenze del carico di lavoro, quali l’accesso all’hypervisor/sistema operativo (OS), il sovraccarico delle risorse, il volume delle transazioni e i tassi di modifica.

Utilizzate integrazioni native, come le API di backup native del database, ad esempio Oracle Recovery Manager (RMAN) o i writer del Volume Shadow Copy Service (VSS) di Microsoft SQL, laddove garantiscano backup coerenti con l’applicazione, coordinamento dei log delle transazioni, backup incrementali efficienti o ripristino granulare.

Inoltre, utilizzare le API per gli snapshot native degli array di storage e del cloud, come le API per gli snapshot di AWS Elastic Block Store (EBS) o l’integrazione con NetApp ONTAP, laddove migliorano la coerenza, la gestione dei log, l’efficienza dei backup incrementali o il ripristino granulare.

### 5. Separare il controllo dei backup e lo storage dall’ambiente di produzione

Limitare l’accesso amministrativo, richiedere l’autenticazione a più fattori quando si gestiscono le credenziali di backup supportate e isolate, ricorrendo a provider di identità autonomi dedicati (ad es. directory locale separata/tenant Okta dedicato) e a vault di gestione degli accessi privilegiati (PAM) con accesso just-in-time (ad es. CyberArk, HashiCorp Vault).

Mantenere copie immutabili o offline, come il blocco degli oggetti S3 con archiviazione WORM (Write-Once-Read-Many) e copie di archiviazione fisiche o con isolamento fisico (ad es. nastri offline o reti di archiviazione isolate).

Una seconda copia sotto il controllo dello stesso sistema di gestione delle identità e degli accessi compromesso non fornisce una protezione indipendente dalla compromissione di quel sistema di gestione delle identità.

### 6. Progettare percorsi sia di ripristino che di backup

Determinare il luogo in cui i carichi di lavoro saranno ripristinati nel caso in cui non sia disponibile la piattaforma originale. Verificare la capacità di rete, le quote cloud, le risorse di calcolo compatibili, le versioni software, le chiavi e le competenze.

Se è possibile ripristinare un backup solo sulla piattaforma di origine guasta, si rischia di incorrere in una dipendenza circolare.

### 7. Testare scenari di guasto rappresentativi

Testare la perdita di macchine virtuali, la perdita di cluster, la cancellazione granulare, il danneggiamento del database, il ransomware, la compromissione degli account cloud e i guasti associati ai siti. Valutare l’RPO e l’RTO effettivi. Non limitarsi a registrare semplicemente come è stato completato il processo.

## Quali sono i problemi più comuni relativi ai backup eterogenei?

I guasti più comuni includono carichi di lavoro mancanti, credenziali scadute, dipendenze applicative incomplete, accesso amministrativo eccessivo e ripristino multipiattaforma non testato.

Le dipendenze multipiattaforma possono causare guasti relativi a identità, autenticazione, sequenziamento e compatibilità delle API. I guasti possono includere scostamenti nell’identità, nell’accesso e nell’autenticazione multipiattaforma, nonché incompatibilità nel sequenziamento dei microservizi e nei protocolli API, tra le piattaforme supportate, non all’interno delle stesse.

### In che modo i nuovi carichi di lavoro creano lacune nella copertura dei backup?

In ambienti con frequenti cambiamenti di provisioning o di configurazione, la manutenzione manuale delle politiche di backup può lasciare temporaneamente non protetti i nuovi carichi di lavoro. Le politiche di backup gestite manualmente possono includere politiche di audit basate su fogli di calcolo e politiche statiche di tagging/etichettatura senza applicazione automatizzata.

Nuove macchine virtuali (VM), database, spazi dei nomi, tenant SaaS o account cloud potrebbero non essere mai inseriti nell’elenco.  
 Una risorsa può risultare ancora visibile tramite una console anche dopo la scadenza delle sue credenziali o se il suo metodo di protezione differisce da quello previsto dalla politica.

Pertanto, è necessario misurare continuamente la copertura. Le risorse di produzione individuate, quali gli elenchi dell’inventario delle API cloud e gli oggetti di gestione degli hypervisor e dei cluster, dovrebbero essere individuate insieme alle risorse protette.

Le risorse protette possono includere record attivi del catalogo dei processi di backup e manifest degli snapshot completati. Il completamento di un processo di backup dimostra l’acquisizione dei dati, non la recuperabilità dell’applicazione.

Inoltre, è necessario evidenziare i carichi di lavoro sconosciuti, esclusi e non conformi, come i database cloud orfani o non protetti e le credenziali obsolete o non valide.

Inoltre, utilizzare tag ed etichette per automatizzare l’assegnazione. I team devono tenere sotto monitoraggio i metadati mancanti o errati come un’inadempienza dei controlli.

### Un backup riuscito significa che un’applicazione è recuperabile?

Di norma, il software di backup conferma di aver letto e archiviato i dati. Non può dimostrare automaticamente la disponibilità di tutte le dipendenze dell’applicazione, quali Active Directory, i provider di identità, i server DNS, i server di gestione delle chiavi (KMS) esterni e i depositi di segreti. Inoltre, non può garantire automaticamente che il servizio ripristinato funzioni.

Per assicurare il ripristino, affidatevi a controlli automatici di avvio o montaggio, verificate l’integrità del database, eseguite scansioni alla ricerca di malware, applicate la convalida a livello di applicazione e richiedete l’accettazione periodica da parte del responsabile.

I servizi ad alto impatto, come i sistemi bancari centrali e di elaborazione delle transazioni, nonché le piattaforme di checkout e di evasione degli ordini nell’e-commerce, necessitano inoltre di test completi del flusso di lavoro, non solo di test limitati all’infrastruttura.

### Quali rischi di sicurezza comporta la gestione centralizzata dei backup?

Una piattaforma unificata può ridurre il numero di console, cataloghi e sistemi di policy gestiti dagli amministratori.

Tuttavia, può anche costituire un bersaglio amministrativo di alto valore. L’effetto di una compromissione può diffondersi nell’intero ambiente IT.

Ciò accade quando un sistema di gestione centrale elimina le politiche, fa scadere le copie — come i set di backup incrementali giornalieri pianificati che non sono ancora stati replicati in un repository offsite o in air-gap — e le istantanee di conservazione a lungo termine destinate all’archiviazione per la conformità normativa che non hanno ancora raggiunto la data di scadenza definita, per poi accedere a ogni carico di lavoro.

Si consiglia di separare i ruoli per ridurre questo rischio. Inoltre, applicate l’accesso amministrativo just-in-time, credenziali separate, utilizzate blocchi di conservazione fissi, inoltro degli audit e host di gestione rinforzati

Inoltre, utilizzate domini di sicurezza distinti, come account Amazon Web Services/abbonamenti Azure completamente isolati e foreste Active Directory on-premise isolate o con air gap, per le copie secondarie, quali bucket S3 WORM con blocco fisso degli oggetti e cartucce a nastro fuori sede isolate o con air gap oppure appliance di archiviazione isolate.

La visibilità centralizzata non dovrebbe tradursi in un’autorità centralizzata senza restrizioni.

### In che modo la deduplicazione influisce sui costi di archiviazione dei backup?

I dati provenienti da carichi di lavoro misti, come database SQL transazionali mescolati a condivisioni di file grezzi non compressi e immagini di infrastrutture desktop virtuali mescolate a archiviazione di contenuti multimediali/video, non vengono deduplicati allo stesso modo.

I database crittografati, i file multimediali compressi, i dischi virtuali soggetti a frequenti modifiche e i dati cloud crittografati lato client possono produrre rapporti di riduzione insoddisfacenti.

Sebbene la deduplicazione globale possa far risparmiare capacità, è possibile fare affidamento su di essa anche per considerazioni relative alle prestazioni, al dominio di errore o alla residenza dei dati, come nel caso di infrastrutture dedicate o segmentate i cui componenti possono guastarsi contemporaneamente, nonché per i pool di prestazioni e l’isolamento geografico e normativo della residenza dei dati.

I modelli di capacità dovrebbero tenere conto dei tassi di variazione specifici del carico di lavoro, della conservazione, del comportamento dei backup completi, dell’overhead fisso, della replica, del traffico in uscita e dello spazio di staging per il ripristino. La pianificazione della capacità non dovrebbe basarsi su un unico rapporto di deduplicazione per tipi di carico di lavoro sostanzialmente diversi.

### Perché è necessario testare il ripristino multipiattaforma?

Le organizzazioni spesso si affidano ai backup per supportare la migrazione al cloud o il ripristino su un hypervisor diverso. In pratica, il ripristino può essere ostacolato da differenze legate a driver, modalità di avvio, formati dei dischi, strutture di rete, identità, funzionalità dei servizi gestiti e licenze delle applicazioni.

Pertanto, il ripristino su una piattaforma diversa dovrebbe essere considerato come un caso d’uso a sé stante che richiede supporto e test documentati. L’esportazione dei dati non equivale alla ricostruzione di un’applicazione operativa.

## È meglio utilizzare un’unica piattaforma di backup o più strumenti specializzati?

Entrambi i modelli possono funzionare. La scelta dipende dal supporto dei carichi di lavoro, dai requisiti di ripristino, dai confini di sicurezza, dalle competenze operative e dai requisiti normativi

Il backup eterogeneo è associato a due approcci comuni. Nello specifico, le organizzazioni possono utilizzare una piattaforma unificata per proteggere vari tipi di carichi di lavoro nell’ambito di un unico catalogo e sistema di policy.

Un approccio federato mantiene i prodotti specializzati e aggiunge monitoraggio, governance o reportistica condivisi.

| Fattore decisionale | Piattaforma di backup unificata | Strumenti specialistici multipli |
| --- | --- | --- |
| Prospettiva operativa | Console, catalogo e reportistica comuni | È necessaria l’aggregazione o la correlazione manuale |
| Profondità del carico di lavoro | Può variare da un’integrazione all’altra | Può essere utile per funzionalità native più approfondite |
| Coerenza delle politiche | Più facile da definire e verificare a livello centrale | Le organizzazioni dovrebbero applicare le politiche in modo coerente su tutti i prodotti |
| Esposizione alla sicurezza | Un unico sistema di gestione centralizzato può aumentare l’esposizione alla sicurezza | Maggior numero di sistemi di gestione centralizzati e credenziali da proteggere |
| Competenze e supporto | Meno modelli operativi | Maggiore conoscenza specialistica e coordinamento con i fornitori |
| Rischio di uscita | Maggiore dipendenza da un unico catalogo o formato di backup | Maggiore complessità operativa e di integrazione |
| Soluzione più adatta | Ambiente IT ampiamente supportato caratterizzato da solide operazioni centralizzate | Carichi di lavoro con esigenze tecniche o normative variabili |

Le organizzazioni possono utilizzare un modello di governance comune anche quando carichi di lavoro diversi richiedono prodotti di backup diversi. L’uso di uno strumento specializzato per database o mainframe può essere giustificato se una piattaforma generica non garantisce coerenza e non soddisfa i requisiti di prestazioni o di ripristino, come nel caso dei cluster Oracle Real Application ad alta produttività che richiedono l’integrazione RMAN “point-in-time” e dei carichi di lavoro su mainframe e sistemi operativi legacy (ad esempio, IBM z/OS o AS/400).

Tuttavia, le organizzazioni dovrebbero tenere conto delle lacune e dei malfunzionamenti, quali carichi di lavoro specializzati non registrati o non protetti, incompatibilità nel ripristino tra piattaforme diverse e errori delle API. Ciò riguarda anche la conformità ai requisiti di conservazione dei dati e la documentazione relativa ai test di ripristino associata a ogni eccezione riguardante i processi operativi standard.

In primo luogo, testare i carichi di lavoro periferici. Non concentrarsi esclusivamente sull’ambiente IT tradizionale basato su VMware o Windows. Successivamente, consolidare gli strumenti, come gli agenti di backup puntuali disparati in esecuzione separata su database Oracle, cluster Kubernetes e sistemi Unix legacy che attualmente richiedono console di gestione individuali e accordi di licenza separati.

Successivamente, verificare se la piattaforma candidata è in grado di ripristinare metadati delle applicazioni, autorizzazioni, log e dipendenze.

Verificate se la piattaforma candidata supporti le versioni distribuite. Accertatevi che il ripristino rimanga possibile anche nel caso in cui il piano di controllo SaaS o il servizio di licenze del fornitore non siano disponibili.

## Come valutare se il backup eterogeneo funziona

Il tasso di successo dei processi di backup da solo non è indicativo della recuperabilità. È possibile misurare la protezione e il ripristino utilizzando una scheda di valutazione più completa:

- **Copertura delle risorse:** percentuale delle risorse di produzione incluse nell’ambito di applicazione, quali infrastrutture cloud di nuova implementazione, namespace Kubernetes e volumi persistenti, protette da una policy approvata
- **Conformità alle policy:** percentuale che soddisfa i requisiti relativi a RPO, conservazione, copie e controlli fissi, quali il blocco degli oggetti immutabili (WORM) e le copie secondarie geograficamente distanti o isolate fisicamente
- **Validità del punto di ripristino:** percentuale dei punti di ripristino campionati che superano i controlli di integrità e di presenza di malware
- **Ripristinabilità testata:** percentuale di applicazioni critiche, quali i sistemi di pianificazione delle risorse aziendali (ERP) (ad es. SAP, Oracle EBS) e i gateway di e-commerce e di pagamento rivolti ai clienti, ripristinate e convalidate entro il periodo di prova richiesto
- **RPO e RTO osservati:** perdita effettiva di dati e tempo di ripristino trascorso durante i test o gli incidenti, come il delta del ripristino puntuale del database (RPO osservato) e il tempo necessario per il ripristino completo dell’applicazione e l’avvio del sistema (RTO osservato).
- **Tempo di deriva della copertura:** per quanto tempo un carico di lavoro nuovo o modificato rimane al di fuori di una politica approvata
- **Età delle eccezioni:** per quanto tempo i carichi di lavoro non supportati o oggetto di deroga rimangono irrisolti
- **Capacità di ripristino in un ambiente isolato a seguito di una compromissione:** se esistono credenziali, reti, risorse di calcolo, chiavi e procedure per eseguire il ripristino al di fuori dell’ambiente compromesso

La classe di carico di lavoro e il livello aziendale possono aiutare a segmentare le metriche, come i carichi di lavoro di livello 0/mission-critical (ad es. core banking, IAM/Active Directory) e quelli di livello 3/non critici (ad es. ambienti interni di sviluppo/test, condivisioni di file di archivio). Un tasso di successo del 98% può nascondere ripetuti fallimenti di alcuni sistemi che generano la maggior parte del rischio aziendale.

## Come Bacula Enterprise supporta gli ambienti di backup eterogenei

[Bacula Enterprise](https://www.baculasystems.com/it/bacula-enterprise-edition/)
 è progettato per proteggere ambienti IT eterogenei senza costringere ogni carico di lavoro a utilizzare lo stesso metodo di backup. Le organizzazioni possono invece gestire carichi di lavoro fisici, virtuali, containerizzati, database, SaaS e cloud attraverso una piattaforma comune di backup e ripristino, utilizzando al contempo integrazioni specifiche per il carico di lavoro ove necessario.

Ciò è importante negli ambienti misti perché, come discusso in precedenza, una macchina virtuale, un database transazionale e un’applicazione Kubernetes possono condividere gli stessi obiettivi di ripristino pur richiedendo meccanismi completamente diversi per creare un punto di ripristino utilizzabile.

Bacula Enterprise supporta questo modello grazie a un’architettura modulare e a un’ampia gamma di plugin e integrazioni dedicati. Gli ambienti supportati includono VMware, Hyper-V, Proxmox, Nutanix, KVM, Xen/XCP-ng, OpenStack, Libvirt, Azure VM e molti altri, oltre ai sistemi fisici Windows, Linux, macOS e Unix. Bacula offre inoltre funzionalità dedicate per Kubernetes, Docker e Red Hat OpenShift.

Per i carichi di lavoro delle applicazioni e dei database, Bacula offre integrazioni per tecnologie quali Microsoft SQL Server, Oracle, PostgreSQL, MySQL, MariaDB, MongoDB, SAP HANA, IBM DB2 e SAP ASE. Anche i carichi di lavoro SaaS come Microsoft 365 e Google Workspace possono essere incorporati nell’ambiente di backup più ampio.

Il risultato è che le organizzazioni possono applicare politiche operative comuni senza ridurre il backup eterogeneo a un approccio basato sul minimo comune denominatore. Ad esempio, gli amministratori possono definire centralmente pianificazioni, periodi di conservazione e politiche di backup, utilizzando al contempo una protezione specifica per l’hypervisor per le macchine virtuali, metodi specifici per i database per i sistemi transazionali e meccanismi specifici per Kubernetes per le applicazioni containerizzate.

Bacula Enterprise può inoltre combinare questi carichi di lavoro con diverse destinazioni di archiviazione per il backup. Le sue integrazioni includono archiviazione su disco, nastro e cloud, nonché interfacce per archiviazione compatibile con S3, Microsoft Azure, Google Cloud, Oracle Cloud e Amazon Glacier. Ciò consente alle organizzazioni di progettare lo storage e la conservazione in base al livello del carico di lavoro, ai requisiti di ripristino e ai vincoli infrastrutturali, anziché limitarsi alla sola piattaforma di origine.

La gestione centralizzata è garantita dalla [BWeb Management Suite](https://www.baculasystems.com/it/bweb-management-suite/)
, che può essere utilizzata per configurare, monitorare e analizzare l’ambiente di backup. Ciò offre agli amministratori una visione operativa comune trasversale alle diverse tecnologie, pur mantenendo i metodi specializzati di backup e ripristino richiesti da ciascun carico di lavoro.

Per le organizzazioni che stanno valutando il consolidamento di diversi prodotti di backup, questa ampia gamma di supporto può ridurre il numero di sistemi di backup separati da gestire. Tuttavia, la copertura dei carichi di lavoro dovrebbe comunque essere valutata in base alle tecnologie e alle versioni effettivamente in uso. L’obiettivo non è semplicemente quello di riunire tutti i carichi di lavoro sotto un’unica console, ma di verificare che ogni sistema critico disponga del metodo di backup appropriato e di un percorso di ripristino collaudato.

## Domande frequenti

### Come dovrebbero essere inclusi i sistemi legacy non supportati in una strategia di backup eterogenea?

Inserirli in un registro formale delle eccezioni che evidenzi il responsabile, l’impatto aziendale, l’attuale metodo di ripristino, i controlli compensativi e la data di dismissione o di risoluzione. Inoltre, un’unica strategia di ripristino può governare più tecnologie di backup.

È possibile ricorrere a misure quali snapshot a livello di storage, dump di database, esportazioni di file, replica o isolamento. Inoltre, testare tutte le soluzioni alternative. Ricordare che, anche se si copiano dati proprietari inaccessibili, non si ottiene un backup utilizzabile.

Una strategia di backup è incompleta finché il ripristino non viene testato.

### Un unico repository immutabile può archiviare in modo sicuro i backup provenienti da ogni ambiente?

Un unico repository immutabile può semplificare la gestione della conservazione e della capacità. Ciò vale laddove il repository supporti l’immutabilità, la velocità di trasmissione, l’isolamento e i controlli normativi richiesti.

Tuttavia, ciò potrebbe concentrare i rischi operativi e di sicurezza. Valutate la separazione dei tenant, le chiavi di crittografia, i domini amministrativi, la residenza dei dati, i domini di guasto, la velocità di ripristino e l’effetto di un’interruzione del repository.

Anche quando le organizzazioni adottano una gestione unificata, i servizi critici, quali i servizi di identità e directory (ad es. Active Directory/Entra ID, infrastruttura a chiave pubblica) e i sistemi finanziari e di elaborazione delle transazioni principali (ad es. SAP, core banking su mainframe), possono giustificare copie di backup separate o livelli di archiviazione distinti in base alla valutazione del rischio.

### Con quale frequenza dovrebbe essere testato il ripristino eterogeneo?

Utilizzate il livello aziendale e il tasso di cambiamento per determinare la frequenza. Applicate una convalida automatizzata per i servizi critici associati a ogni backup. Non dimenticate le esercitazioni programmate di ripristino delle applicazioni, come la simulazione di cutover del disaster recovery (DR) full-stack e il ripristino isolato in ambiente controllato in caso di ransomware.

È possibile testare i carichi di lavoro di livello inferiore con minore frequenza. La frequenza dei test dovrebbe derivare dall’impatto sul business, dai requisiti normativi, dalla frequenza delle modifiche e dagli obiettivi di ripristino.

Tuttavia, è necessario campionare tutti i tipi di piattaforme, i processi e le destinazioni rilevanti utilizzati per ripristinare un carico di lavoro. Eseguire nuovamente i test dopo aggiornamenti importanti, migrazioni di dati, modifiche alle identità o cambiamenti nell’architettura. Misurare il successo del ripristino, non solo quello del backup.

Informazioni sull'autore

[https://www.linkedin.com/in/rob-morrison-3aa443/](https://www.linkedin.com/in/rob-morrison-3aa443/)

Rob Morrison è il direttore marketing di Bacula Systems. Ha iniziato la sua carriera nel marketing IT con Silicon Graphics in Svizzera, ottenendo ottimi risultati in vari ruoli di gestione del marketing per quasi 10 anni. Nei 10 anni successivi, Rob ha ricoperto anche diverse posizioni di gestione del marketing in JBoss, Red Hat e Pentaho, assicurando la crescita della quota di mercato di queste note aziende. Si è laureato all'Università di Plymouth e ha conseguito una laurea ad honorem in Digital Media and Communications e ha completato un programma di studi all'estero.

*Messaggi correlati*

[https://www.baculasystems.com/it/it-blog/backup-e-ripristino-del-mainframe/](https://www.baculasystems.com/it/it-blog/backup-e-ripristino-del-mainframe/)
[Backup e ripristino dei mainframe: strategie moderne per sistemi aziendali resilienti](https://www.baculasystems.com/it/it-blog/backup-e-ripristino-del-mainframe/)

Marzo 30, 2026

[https://www.baculasystems.com/it/it-blog/cassandra-backup-restore/](https://www.baculasystems.com/it/it-blog/cassandra-backup-restore/)
[Guida completa al backup e al ripristino del database Cassandra](https://www.baculasystems.com/it/it-blog/cassandra-backup-restore/)

Aprile 23, 2026

[https://www.baculasystems.com/it/it-blog/mongodb-backup-ripristino/](https://www.baculasystems.com/it/it-blog/mongodb-backup-ripristino/)
[Guida completa al backup e al ripristino del database MongoDB](https://www.baculasystems.com/it/it-blog/mongodb-backup-ripristino/)

Marzo 16, 2026

[https://www.baculasystems.com/it/it-blog/le-migliori-pratiche-di-backup-e-ripristino-di-openstack/](https://www.baculasystems.com/it/it-blog/le-migliori-pratiche-di-backup-e-ripristino-di-openstack/)
[Backup e ripristino OpenStack: Migliori pratiche, metodi e soluzioni integrati](https://www.baculasystems.com/it/it-blog/le-migliori-pratiche-di-backup-e-ripristino-di-openstack/)

Novembre 14, 2023

[https://www.baculasystems.com/it/it-blog/openstack-vs-vmware/](https://www.baculasystems.com/it/it-blog/openstack-vs-vmware/)
[OpenStack e VMware: Guida comparativa delle piattaforme di virtualizzazione](https://www.baculasystems.com/it/it-blog/openstack-vs-vmware/)

Giugno 28, 2025

[https://www.baculasystems.com/it/it-blog/strategia-di-backup-aziendale/](https://www.baculasystems.com/it/it-blog/strategia-di-backup-aziendale/)
[Le migliori pratiche e la guida per la strategia di backup aziendale](https://www.baculasystems.com/it/it-blog/strategia-di-backup-aziendale/)

Febbraio 22, 2024