Condividi tramite

Backup continuo con ripristino temporizzato in Azure Cosmos DB

SI APPLICA A: NoSQL MongoDB Gremlin Tabella

La funzionalità di ripristino temporizzato di Azure Cosmos DB risulta utile in numerosi scenari, tra cui:

  • Ripristino da un'operazione accidentale di scrittura o di eliminazione in un contenitore.
  • Ripristino di un account, un database o un contenitore eliminati.
  • Ripristino in qualsiasi area, in cui erano disponibili backup, in corrispondenza del punto di ripristino.

Azure Cosmos DB esegue il backup dei dati in background senza utilizzare velocità effettiva aggiuntiva (UR) di cui è stato effettuato il provisioning o senza influire sulle prestazioni e la disponibilità del database. I backup continui vengono eseguiti in ogni area in cui è presente l'account. Ad esempio, un account può avere un'area di scrittura negli Stati Uniti occidentali e aree di lettura negli Stati Uniti orientali e negli Stati Uniti orientali 2. È quindi possibile eseguire il backup di queste aree di replica in un account di archiviazione di Azure remoto in ogni rispettiva area. Per impostazione predefinita, ogni area archivia il backup in account di archiviazione con ridondanza locale. Se l'area dispone di zone di disponibilità abilitate, il backup viene archiviato negli account di archiviazione con ridondanza della zona.

Diagramma che illustra come viene eseguito il backup di un contenitore in più aree.

L'intervallo di tempo disponibile per il ripristino (noto anche come periodo di conservazione) è il valore inferiore delle due opzioni seguenti: 30 giorni e 7 giorni.

L'opzione selezionata dipende dal livello scelto del backup continuo. La temporizzazione del ripristino può essere qualsiasi timestamp compreso nel periodo di conservazione purché non superi il punto in cui è stata creata la risorsa. Nella modalità di coerenza assoluta i backup eseguiti nell'area di scrittura sono più aggiornati rispetto alle aree di lettura. Le aree di lettura potrebbero presentare un ritardo dovuto alla rete o ad altri problemi temporanei. Durante il ripristino, è possibile ottenere il timestamp ripristinabile più recente per una risorsa specificata in una determinata area. Facendo riferimento al timestamp ripristinabile più recente, è possibile confermare che i backup delle risorse sono fino al timestamp specificato e possono essere ripristinati in tale area.

Attualmente, è possibile ripristinare in un altro account i contenuti di un account Azure Cosmos DB (API per NoSQL o MongoDB, API per Tabella, API per Gremlin) relativi a un momento specifico. È possibile eseguire questa operazione di ripristino tramite il portale di Azure, l'interfaccia della riga di comando di Azure, Azure PowerShell o i modelli di Azure Resource Manager.

Ridondanza dell'archiviazione di backup

Per impostazione predefinita, Azure Cosmos DB archivia i dati di backup in modalità continua in BLOB di archiviazione con ridondanza locale. Per le aree per cui è configurata la ridondanza della zona, il backup viene archiviato in BLOB di archiviazione con ridondanza della zona. Con la modalità di backup continuo non è possibile aggiornare la ridondanza dell'archivio di backup.

Diverse modalità di ripristino

Con la modalità di backup continuo sono supportati due modi per ripristinare contenitori e database eliminati. Possono essere ripristinati in un nuovo account o in un account esistente. La scelta tra queste due modalità dipende dagli scenari. Nella maggior parte dei casi, è preferibile ripristinare i contenitori eliminati e i database in un account esistente. In questo modo si evita il costo del trasferimento dei dati necessario per il ripristino in un nuovo account. Per gli scenari in cui è stata eseguita la modifica accidentale dei dati, il ripristino in un nuovo account potrebbe essere l'opzione preferita.

Che cosa viene ripristinato in un nuovo account?

In uno stato stabile tutte le mutazioni eseguite nell'account di origine (inclusi database, contenitori ed elementi) vengono sottoposte a backup in modo asincrono entro 100 secondi. Se il supporto di backup di Archiviazione di Azure è inattivo o non disponibile, le mutazioni vengono salvate in modo permanente in locale fino a quando il supporto non diventa disponibile. Le mutazioni vengono quindi eliminate per evitare la perdita di fedeltà delle operazioni che possono essere ripristinate.

È possibile scegliere di ripristinare qualsiasi combinazione di contenitori di velocità effettiva con provisioning, database di velocità effettiva condivisi o l'intero account. Questa azione ripristina tutti i dati e le relative proprietà di indice in un nuovo account. Il processo di ripristino garantisce che tutti i dati ripristinati in un account, un database o un contenitore siano coerenti fino all'ora di ripristino specificata. La durata del ripristino dipende dalla quantità di dati da ripristinare. L'impostazione di coerenza dell'account di database appena ripristinata corrisponde alle impostazioni di coerenza dell'account del database di origine.

Note

Con la modalità di backup continuo i backup vengono eseguiti in tutte le aree in cui è disponibile l'account Azure Cosmos DB. I backup eseguiti per ogni account dell'area includono la ridondanza locale per impostazione predefinita e la ridondanza della zona se nell'account è abilitata la funzionalità zona di disponibilità per tale area. L'azione di ripristino consente di eseguire il ripristino dei dati sempre in un nuovo account.

Che cosa non viene ripristinato?

Dopo il ripristino temporizzato non vengono ripristinate le configurazioni seguenti:

  • Un subset di contenitori in un database con velocità effettiva condivisa non può essere ripristinato. L’intero database può essere completamente ripristinato.
  • Firewall, rete virtuale, controllo degli accessi in base al ruolo del piano dati o impostazioni dell'endpoint privato.
  • Tutte le aree dell'account di origine.
  • Stored procedure, trigger, funzioni definite dall'utente.
  • Assegnazioni del controllo degli accessi in base al ruolo.

È possibile aggiungere queste configurazioni all'account ripristinato al termine del ripristino.

Timestamp ripristinabile per account attivi

Per ripristinare gli account attivi Azure Cosmos DB che non sono eliminati, è consigliabile identificare sempre il timestamp ripristinabile più recente per il contenitore. È quindi possibile usare questo timestamp per ripristinare l'account alla versione più recente.

Scenari di ripristino

La funzionalità di ripristino temporizzato supporta gli scenari seguenti. Gli scenari da 1 a 3 illustrano come attivare un ripristino se il timestamp di ripristino è noto in anticipo. Tuttavia, potrebbero verificarsi scenari in cui non si conosce l'ora esatta dell'eliminazione o del danneggiamento accidentale. Gli scenari 4 e 5 illustrano come individuare il timestamp di ripristino usando le nuove API del feed di eventi nel database o nei contenitori ripristinabili.

Diagramma che mostra gli eventi del ciclo di vita con timestamp per un account ripristinabile.

  • Scenario 1 - Ripristinare l'account eliminato: tutti gli account eliminati che è possibile ripristinare sono visibili dal riquadro Ripristina . Ad esempio, considerare il caso dell'account A che viene eliminato in corrispondenza del timestamp T3. In questo caso il timestamp appena prima di T3, località, nome dell'account di destinazione, gruppo di risorse e nome dell'account di destinazione sono sufficienti per eseguire il ripristino dal portale di Azure, Da PowerShell o dall'interfaccia della riga di comando.

    Eventi del ciclo di vita con timestamp per un database e un contenitore ripristinabili.

  • Scenario 2- Ripristinare i dati di un account in una determinata area: ad esempio, se l'account A esiste in due aree Stati Uniti orientali e Stati Uniti occidentali al timestamp T3. Se è necessaria una copia dell'account A negli Stati Uniti occidentali, è possibile eseguire un ripristino temporizzato dal portale di Azure, Da PowerShello dall'interfaccia della riga di comando con Stati Uniti occidentali come posizione di destinazione.

  • Scenario 3: eseguire il ripristino da un'operazione di scrittura o eliminazione accidentale all'interno di un contenitore con un timestamp di ripristino noto: ad esempio, se si sa che il contenuto del contenitore 1 all'interno del database 1 è stato modificato accidentalmente al timestamp T3. È possibile eseguire un ripristino temporizzato dal portale di Azure, Da PowerShell o dall'interfaccia della riga di comando in un altro account al timestamp T3 per ripristinare lo stato desiderato del contenitore.

  • Scenario 4: ripristinare un account a un momento precedente prima dell'eliminazione accidentale del database: nel portale di Azure è possibile usare il riquadro feed eventi per determinare quando un database è stato eliminato e trovare il tempo di ripristino. Analogamente, con l'interfaccia della riga di comando di Azure e PowerShell è possibile individuare l'evento di eliminazione del database enumerando il feed di eventi del database e quindi attivare il comando di ripristino con i parametri richiesti.

  • Scenario 5: ripristinare un account a un momento precedente prima dell'eliminazione accidentale o della modifica delle proprietà del contenitore: nel portale di Azure è possibile usare il riquadro feed eventi per determinare quando un contenitore è stato creato, modificato o eliminato per trovare il tempo di ripristino. Analogamente, con l'interfaccia della riga di comando di Azure e PowerShell, è possibile individuare tutti gli eventi del contenitore enumerando il feed di eventi del contenitore e quindi attivare il comando di ripristino con i parametri richiesti.

Autorizzazioni

Azure Cosmos DB consente di isolare e limitare le autorizzazioni di ripristino per un account di backup continuo a un ruolo o a un'entità di sicurezza specifica. Per altre informazioni, vedere Gestire le autorizzazioni per ripristinare un account Azure Cosmos DB.

Informazioni sul ripristino dell'account di scrittura in più aree

Le scritture eseguite nell'area hub vengono immediatamente confermate e sottoposte a backup asincrono entro 100 secondi. Negli account di scrittura in più aree, tutte le mutazioni eseguite nell'area satellite vengono inviate all'area dell'hub per la conferma. L'area hub verifica se è necessaria una risoluzione dei conflitti , assegna un timestamp di risoluzione dei conflitti dopo la risoluzione dei conflitti e invia il documento all'area satellite. L'area satellite esegue il backup dei documenti solo dopo la ricezione della conferma dall'hub. In breve, il processo di ripristino ripristina solo i documenti confermati dalla regione hub al momento del punto di ripristino.

Cosa succede per il ripristino di un account di scrittura multi-regione?

  • Le mutazioni che devono ancora essere confermate dal timestamp di ripristino non vengono ripristinate.
  • Le raccolte con criteri di risoluzione dei conflitti personalizzati vengono reimpostate al criterio 'ultimo che scrive vince' basato sul timestamp.

Note

Il ripristino dall'area satellite è più lento rispetto al ripristino nell'area dell'hub perché l'account in più aree possa risolvere le scritture provvisorie locali come confermate o eseguire un'azione per eseguirne il rollback.

Per saperne di più sui timestamp in un account abilitato per più scritture, consultare Informazioni sui timestamp.

Scenario di esempio: se è disponibile un account di scrittura in più aree con le due aree Stati Uniti orientali e Stati Uniti occidentali, dove Stati Uniti orientali è l'area dell'hub, prendere in considerazione la sequenza di eventi seguente:

  • T1: il client scrive un documento Doc1 negli Stati Uniti orientali (poiché Stati Uniti orientali è l'area hub, la scrittura viene immediatamente confermata)

  • T2: Il client scrive un documento Doc2 negli Stati Uniti occidentali

  • T3: Stati Uniti occidentali invia Doc2 agli Stati Uniti orientali per la conferma

  • T4: Gli Stati Uniti orientali ricevono Doc2, confermano il documento e rinviano Doc2 agli Stati Uniti occidentali

  • T5: Stati Uniti occidentali ha ricevuto conferma Doc2

In questo scenario, se il timestamp di ripristino fornito è T3 per l'area dell'hub come origine, viene ripristinato solo Doc1. Doc2 non è stato confermato da T3 dell'hub. Doc2 viene ripristinato come ripristino in T4 se l'area satellite contiene solo doc1 perché doc2 non è ancora confermato, solo nel caso in cui timestamp di ripristino sia superiore a T4.

Prezzi

L'account Azure Cosmos DB con backup continuo di 30 giorni prevede un addebito mensile aggiuntivo per archiviare il backup. Sia il livello per 30 giorni che quello per sette giorni di backup continuo comportano addebiti per il ripristino dei dati. Il costo di ripristino viene aggiunto ogni volta che si avvia l'operazione di ripristino. Se si configura un account con backup continuo ma non si ripristinano i dati, nella fattura viene incluso solo il costo dell'archivio di backup.

L'esempio seguente si basa sul prezzo di un account Azure Cosmos DB distribuito negli Stati Uniti occidentali. I prezzi e i calcoli possono variare a seconda dell'area in uso. Per informazioni più aggiornate sui prezzi, vedere la pagina dei prezzi di Azure Cosmos DB.

  • Tutti gli account abilitati con criteri di backup continuo per 30 giorni sono soggetti a un addebito mensile per l'archivio di backup che viene calcolato nel modo seguente:

    0,20 USD/GB * Dimensioni dei dati in GB nell'account * Numero di aree

  • Ogni chiamata all'API di ripristino comporta un addebito una tantum. L'addebito è una funzione della quantità di dati ripristinati:

    $ 0,15 USD/GB * Dimensioni dei dati in GB

Ad esempio, se sono presenti 1 TB di dati in due aree:

  • Il costo dell'archiviazione di backup viene calcolato come 1000 * 0,20 * 2 = $ 400 al mese

  • Il costo di ripristino viene calcolato come 1000 * 0,15 = $ 150 per ripristino

Suggerimento

Per altre informazioni sulla misurazione dell'utilizzo corrente dei dati dell'account Azure Cosmos DB, vedere Esplorare le informazioni dettagliate su Azure Cosmos DB in Monitoraggio di Azure. Il livello continuo di 7 giorni non comporta addebiti per il backup dei dati.

Livello continuo di 30 giorni rispetto al livello di 7 giorni

  • Il periodo di conservazione per un livello è di 30 giorni rispetto a 7 giorni per un altro livello.
  • Il livello di conservazione di 30 giorni viene addebitato per l'archiviazione di backup. Il livello di conservazione di sette giorni non viene addebitato.
  • Il ripristino viene sempre addebitato in entrambi i livelli.

Durata (TTL)

  • Il processo di ripristino predefinito ripristina tutte le proprietà di un contenitore, inclusa la configurazione TTL per impostazione predefinita. Ciò può comportare l'eliminazione dei dati se il ripristino viene eseguito senza disabilitare il TTL. Per impedire l'eliminazione, passare un parametro per disabilitare TTL in PowerShell (-DisableTtl $true) o nell'interfaccia della riga di comando (--disable-ttl True) durante l'esecuzione del ripristino.

Chiavi gestite dal cliente

Per informazioni, vedere Come influiscono le chiavi gestite dal cliente sui backup continui:

  • Come configurare l'account Azure Cosmos DB quando si usano chiavi gestite dal cliente con i backup continui.
  • In che modo le chiavi gestite dal cliente influiscono sui ripristini?

Limitazioni correnti

Attualmente la funzionalità di ripristino temporizzato presenta le limitazioni seguenti:

  • Per il backup continuo sono supportate le API di Azure Cosmos DB for SQL, MongoDB, Gremlin e Table. L'API per Cassandra non è ancora supportata.

  • Collegamento ad Azure Synapse è disponibile a livello generale per gli account di database che usano la modalità di backup continuo. La situazione opposta, la modalità di backup continua per gli account abilitati per collegamento a Synapse, è disponibile in anteprima pubblica. Attualmente, i clienti che hanno disabilitato Collegamento a Synapse dai contenitori non possono eseguire la migrazione al backup continuo. Inoltre l'archivio analitico non è incluso nei backup. Per altre informazioni, vedere Backup dell'archivio analitico.

  • L'account ripristinato viene creato nella stessa area in cui risiede l'account di origine. Non è possibile ripristinare un account in un'area in cui non esisteva l'account di origine.

  • La finestra di ripristino dura solo 30 giorni per il livello per 30 giorni e sette giorni per il livello per sette giorni. Questi livelli possono essere scambiati, ma non è possibile modificare le quantità effettive (7 o 30). Inoltre, se si passa dal livello per 30 giorni al livello per sette giorni, è probabile che si verifichi una perdita di dati nei giorni successivi al settimo.

  • I backup non sono automaticamente resistenti al ripristino di emergenza geografico. Un'altra area deve essere aggiunta in modo esplicito per la resilienza dell'account e del backup.

  • Mentre è in corso un ripristino, non modificare o eliminare i criteri di gestione delle identità e degli accessi (IAM). Questi criteri concedono le autorizzazioni per l'account per modificare qualsiasi rete virtuale, configurazione del firewall.

  • Gli account Azure Cosmos DB per MongoDB con backup continuo non supportano la creazione di un indice univoco per una raccolta esistente. Per un account di questo tipo, è necessario creare indici univoci insieme alla creazione della raccolta, che deve e può essere eseguita solo usando i comandi di creazione dell'estensione della raccolta.

  • Dopo il ripristino, è possibile che per determinate raccolte l'indice coerente venga ricompilato. È possibile controllare lo stato dell'operazione di ricompilazione tramite la proprietà IndexTransformationProgress.

  • Non è possibile aggiungere, aggiornare o eliminare indici univoci nell'API per MongoDB quando si crea un account in modalità di backup continuo. Non possono essere modificati neanche durante la migrazione di un account dalla modalità periodica alla modalità continua.

  • Il ripristino in modalità continua potrebbe non ripristinare l'impostazione della larghezza di banda valida al momento del punto di ripristino.

Passaggi successivi

  • Last updated on