Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Siti DR e strategie DR di Amazon RDS comuni
Un sito di disaster recovery (DR) è una posizione secondaria utilizzata da un'organizzazione per ripristinare l'infrastruttura e le applicazioni IT critiche per l'azienda quando un sito primario è stato colpito da un disastro. I siti di DR sono spesso costruiti in una posizione remota per garantire che il disastro che colpisce il sito principale non influisca anche sul sito secondario. I siti di DR disponibili all'interno dell'utente AWS possono essere generalmente classificati come DR vicini e remoti:
+ Il Near DR viene spesso definito come disaster recovery interno all'area geografica. La soluzione DR è configurata tra le zone di disponibilità per proteggere il sistema in caso di interruzione della zona di disponibilità o manutenzione pianificata.
+ Far DR viene spesso definito disaster recovery interregionale. La soluzione è configurata Regioni AWS per proteggere il sistema da interruzioni a livello regionale o per eseguire passaggi pianificati per soddisfare le politiche di conformità.
## DR sincrono
Nel DR sincrono, i dati vengono replicati sul sito DR contemporaneamente alla creazione o all'aggiornamento di nuovi dati sul sito primario. Per ottenere una soluzione DR sincrona per i database dell'edizione standard, è possibile utilizzare l'implementazione Multi-AZ.
L'implementazione Multi-AZ (near DR) è una soluzione AWS gestita Near-DR che fornisce la replica sincrona del database RDS su un'istanza di standby in una zona di disponibilità diversa all'interno della stessa regione. Se il database primario non è disponibile a causa di un'interruzione a livello di zona di disponibilità, promuove AWS automaticamente il database in standby al ruolo principale. Ciò garantisce una perdita di dati e tempi di inattività minimi. Tuttavia, è importante notare che l'implementazione Multi-AZ non protegge dalle interruzioni a livello regionale. Inoltre, non fornisce alcuna funzionalità di DR al di fuori di. Cloud AWS
## Opzioni di DR asincrono
Nel DR asincrono, la replica non viene eseguita contemporaneamente alle modifiche apportate al sistema primario. I dati vengono replicati solo agli intervalli definiti dall'obiettivo del punto di ripristino. Per implementare una soluzione DR asincrona, è possibile utilizzare le seguenti opzioni:
+ [Istantanee](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html) automatizzate gestite tramite AWS Backup : AWS Backup è un servizio di backup completamente gestito che automatizza il backup e il ripristino del database Amazon RDS in base alle impostazioni di point-in-time ripristino (PITR). Con AWS Backup, puoi scattare istantanee, creare pianificazioni di backup, politiche di conservazione e piani di backup per proteggere i dati da cancellazioni accidentali, danneggiamento o guasti hardware. È possibile ripristinare il database su una nuova istanza RDS nella stessa regione Regione AWS o in un'altra.
AWS Backup è un'opzione di DR attiva-passiva perché è necessario avviare manualmente il processo di ripristino in caso di errore del database primario. È possibile utilizzarla AWS Backup in combinazione con un'implementazione Multi-AZ, combinando soluzioni sincrone e asincrone per fornire un ulteriore livello di protezione contro la perdita di dati.
+ Replica degli snapshot Amazon RDS PITR: gli snapshot RDS sono un'opzione di disaster recovery manuale. Definisci una configurazione di point-in-time snapshot per la tua istanza di database RDS e le istantanee vengono archiviate in Amazon Simple Storage Service (Amazon S3). È quindi possibile abilitare la replica tra regioni per replicare le modifiche dal database primario al database di standby in una regione diversa.
La replica degli snapshot di Amazon RDS PITR è un'opzione di DR attiva-passiva, poiché è necessario avviare manualmente il processo di ripristino e promuovere il database in standby al ruolo principale in caso di guasto del database primario originale. Tuttavia, questa opzione offre maggiore flessibilità rispetto alla distribuzione Multi-AZ e può essere utilizzata per proteggersi da interruzioni a livello regionale.