Il disaster recovery comincia dai requisiti, non dai prodotti

Prima di scegliere una tecnologia, un progetto SAP su Azure deve avere due numeri concordati con il business: quanto dato si può perdere (RPO) e in quanto tempo il sistema deve tornare operativo (RTO). Sono i due parametri che decidono tutto il resto, e quasi sempre sono diversi per sistema: un production ERP non ha gli stessi requisiti di un sandbox o di un sistema di reporting.

Il secondo passo è distinguere i livelli di protezione, perché l’esame li mescola di proposito. Un availability set protegge dal guasto di un rack o da un update domain durante la manutenzione pianificata. Una availability zone protegge dal guasto di un intero datacenter dentro la region, ed è il livello tipico dell’alta disponibilità di un cluster Pacemaker o Windows Server Failover Cluster con la replica sincrona del database. Nessuno dei due protegge dall’indisponibilità della region: quella richiede una secondary region, cioè disaster recovery vero. Alta disponibilità e disaster recovery non sono lo stesso design con parametri diversi: sono due piani che convivono.

Cosa si replica e cosa si ricostruisce

Un landscape SAP non va replicato in blocco. Gli application server sono in larga parte ricostruibili: sono installazioni ripetibili, i loro dati vivono nel database, e in molti scenari conviene tenerne in DR un set ridotto (o spento) e portarli a dimensione al momento del failover. Il database è l’elemento che non si può ricostruire: va replicato con il suo meccanismo nativo verso la region secondaria — HANA System Replication in modalità asincrona per HANA, Always On availability group per SQL Server — perché è la replica che conosce la consistenza transazionale e offre l’RPO migliore.

Restano i componenti condivisi: le share dell’ASCS/SCS, /sapmnt, i volumi dati. Se poggiano su Azure NetApp Files, la replica è quella nativa del servizio (cross-region replication), non un prodotto generico. La regola operativa è semplice: ogni layer si replica con lo strumento che ne comprende la semantica.

Dove entra Azure Site Recovery

Azure Site Recovery copre le macchine per cui la replica applicativa non esiste, non è supportata o non conviene: application server, SAP Web Dispatcher, jump box, server di gestione. Replica i managed disk a livello di blocco verso la region secondaria e non richiede compute acceso nel sito di DR: si paga la replica e lo storage, il compute solo quando il failover avviene. Questo lo rende interessante anche sul piano della cost optimization.

Il valore aggiunto sono i recovery plan, che impongono l’ordine di avvio — prima il database, poi ASCS, poi gli application server — e possono eseguire script durante il failover. Il limite è altrettanto importante: per il layer database ASR non è la scelta indicata, e alcuni componenti (volumi ANF, tipi di disco non supportati) restano fuori dal suo perimetro. Un design realistico è quindi ibrido: replica nativa per il DB, ASR per il resto, orchestrazione unica.

Il backup è un piano separato, non un sostituto

La replica propaga tutto, errori inclusi: una cancellazione errata o una corruzione logica arriva nella region secondaria in pochi secondi. Solo il backup consente di tornare indietro nel tempo. Azure Backup offre backup a livello di database per i motori SAP supportati, in primis Azure Backup for SAP HANA, che si integra con gli strumenti nativi del database e permette il ripristino puntuale gestendo anche i log backup; la loro frequenza è ciò che determina l’RPO del piano di backup. Per le VM non-database resta il backup a livello di macchina, che va reso application-consistent per essere davvero utilizzabile.

Le decisioni di piano sono retention, ridondanza del vault e capacità di ripristinare in un’altra region. E soprattutto il punto che si dimentica: un piano di ripristino non provato non è un piano. Il test va calendarizzato, con test failover in una rete isolata che non interrompe la replica, prove di restore reali e un runbook aggiornato dopo ogni cambiamento del landscape.

Trappole tipiche d’esame

  • Proteggere HANA in una seconda region → HANA System Replication asincrona, non Azure Site Recovery: per il layer database la replica nativa è la strada indicata; ASR è pensato per le VM in cui non esiste una replica applicativa.
  • /hana/data e /hana/log su Azure NetApp Files → cross-region replication di ANF: ASR replica managed disk, non volumi ANF; se lo storage è ANF va replicato con il meccanismo del servizio.
  • Recuperare da una cancellazione dati di ieri → restore da backup, non failover: la replica ha già propagato l’errore logico nella region secondaria; solo un point-in-time restore riporta indietro lo stato.
  • Ridurre il costo del sito di DR → application server ridimensionati o non accesi, con resize al failover: con ASR il compute si paga al failover; se l’RTO è stretto va però considerata la disponibilità di capacità nella region secondaria.
  • “Siamo zone-redundant, quindi il DR è coperto” → falso: le availability zone proteggono dal guasto di un datacenter dentro la region; l’evento regionale richiede una secondary region.
  • Failover con ordine di avvio corretto → recovery plan di Site Recovery: un failover manuale VM per VM allunga l’RTO e sbaglia le dipendenze fra database, ASCS e application server.