Domande generali su Azure Site Recovery

Site Recovery favorisce l'attuazione della strategia di continuità aziendale e ripristino di emergenza mediante la gestione e l'automatizzazione delle operazioni di replica delle macchine virtuali di Azure tra le aree, delle macchine virtuali e dei server fisici locali in Azure o in un data center secondario. Altre informazioni.

No, Azure Site Recovery non supporta i carichi di lavoro Docker in esecuzione nelle macchine virtuali. Per proteggere queste macchine virtuali con Site Recovery, escludere i dischi in cui è installato Docker.

Esistono varie misure adottate da Site Recovery per garantire l'integrità dei dati. Viene stabilita una connessione sicura tra tutti i servizi tramite il protocollo HTTPS. In questo modo si garantisce che qualsiasi malware o entità esterna non possa manomettere i dati. Un'altra misura adottata è l'uso di checksum. Il trasferimento dei dati tra l'origine e la destinazione viene eseguito calcolando i checksum dei dati tra di essi. In questo modo si garantisce che i dati trasferiti siano coerenti.

Azure non supporta indirizzi MAC persistenti e pertanto non è possibile usare software con modelli di licenza basati su MAC sia per la migrazione locale che per il ripristino di emergenza da locale ad Azure.

No, Azure Site Recovery attualmente non supporta dischi temporanei.

L'agente di Servizi di ripristino di Microsoft Azure viene usato per la configurazione/registrazione con i servizi di Site Recovery e per il monitoraggio dell'integrità di tutti i componenti. Questo componente è uno dei blocchi predefiniti di base dell'intera infrastruttura locale di Azure Site Recovery. Consente di replicare i carichi di lavoro in un'altra area di Azure da un sito locale e di eseguire il failover in Azure in un'emergenza.

Sì, Site Recovery supporta i modelli di infrastruttura dedicati e condivisi.

No. L'identità del tenant rimane anonima. Per i tenant non è necessario l'accesso al portale di Site Recovery. Solo l'amministratore del provider di servizi interagisce con il portale.

Quando si esegue la replica in Azure, i dati dell'applicazione vengono inviati ad Archiviazione di Azure, ma non al servizio Site Recovery. I dati vengono crittografati in transito (HTTPS) e rimangono crittografati in Azure.

No. La fatturazione di Azure avviene direttamente con il provider di servizi. I provider di servizi sono responsabili della generazione di fatture specifiche per i tenant.

No, i dati vengono replicati nelle risorse di archiviazione di Azure nella sottoscrizione. Quando si esegue un failover di test (drill di ripristino di emergenza) o un failover effettivo, Site Recovery crea automaticamente macchine virtuali nella sottoscrizione.

Sì.

Sono supportate distribuzioni basate su Azure Pack, Cloud Platform System e System Center (2012 e versioni successive). Alter informazioni sull'integrazione di Azure Pack e Site Recovery.

No, è possibile replicare le macchine virtuali Hyper-V solo in Azure.

Vedere i dettagli sui prezzi di Site Recovery.

È possibile usare la funzione Calcolatore dei prezzi per stimare i costi quando si usa Site Recovery.

Per una stima dettagliata dei costi, eseguire lo strumento Piano di distribuzione per VMware o Hyper-V e usare il report di stima dei costi.

Sì, sono previsti costi aggiuntivi per l'utilizzo dell'account di archiviazione nella cache durante la replica di macchine virtuali con Site Recovery. I costi dell'account di archiviazione della cache rimangono invariati quando l'archiviazione di replica è di tipo managed disks o dischi non gestiti.

Sì. Per ogni istanza protetta non vengono addebitati costi per Azure Site Recovery per i primi 31 giorni. Ad esempio, se si proteggono 10 istanze per gli ultimi sei mesi e si connette un'istanza di 11a ad Azure Site Recovery, non sono previsti addebiti per l'11a istanza per i primi 31 giorni. Per le prime 10 istanze continueranno a venire addebitati i costi per Azure Site Recovery, in quanto sono state protette per più di 31 giorni.

Sì, anche se Site Recovery è gratuito durante i primi 31 giorni di un'istanza protetta, possono venire addebitati i costi per Archiviazione di Azure, transazioni di archiviazione e trasferimento dei dati. Per una macchina virtuale ripristinata possono venire addebitati anche i costi di calcolo di Azure.

Non è previsto alcun costo separato per l'analisi del ripristino di emergenza. Dopo la creazione della macchina virtuale dopo il failover di test verranno addebitati costi di calcolo.

No, Site Recovery non intercetta i dati replicati né raccoglie informazioni su ciò che è in esecuzione sulle macchine virtuali o sui server fisici. I dati di replica vengono scambiati tra host Hyper-V, hypervisor VMware o server fisici e Archiviazione di Azure o il sito secondario. Site Recovery non è in grado di intercettare i dati. Al servizio Site Recovery vengono inviati solo i metadati necessari per gestire la replica e il failover.

Site Recovery è certificato ISO 27001:2013, 27018, HIPAA e DPA e le valutazioni SOC2 e FedRAMP JAB sono in fase di completamento.

Sì. Quando si crea un insieme di credenziali di Site Recovery in un'area, tutti i metadati necessari per abilitare e gestire la replica e il failover restano all'interno dei confini di tale area geografica.

Per la replica di macchine virtuali e server fisici in Azure, sono supportate sia la crittografia in transito che la crittografia inattiva (in Azure).

Sì, il protocollo TLS 1.2 viene applicato per impostazione predefinita per lo scenario Site Recovery da Azure ad Azure.

Gli agenti di mobilità installati negli elementi replicati comunicano con il server di elaborazione solo sul protocollo TLS 1.2. Tuttavia, la comunicazione dal server di configurazione ad Azure e dal server di elaborazione ad Azure può avvenire sul protocollo TLS 1.1 o 1.0. Seguire le indicazioni per applicare TLS 1.2 a tutti i server di configurazione e i server di elaborazione configurati dall'utente.

Tutte le comunicazioni tra i microservizi di Azure Site Recovery avvengono mediante il protocollo TLS 1.2. Site Recovery usa provider di sicurezza configurati nel sistema operativo e usa il protocollo TLS più recente disponibile. Sarà necessario abilitare in modo esplicito il protocollo TLS 1.2 nel registro perché Site Recovery inizi a usare TLS 1.2 per la comunicazione con i servizi.

È possibile attivare l'identità gestita dell'insieme di credenziali di servizi di ripristino dall'impostazione Identità. Dopo aver registrato l'insieme di credenziali con Microsoft Entra ID, è possibile passare agli account di archiviazione e assegnare le assegnazioni di ruolo seguenti all'insieme di credenziali:

• Account di archiviazione basati su Resource Manager (tipo Standard):
  • Collaboratore
  • Collaboratore dati BLOB di archiviazione
• Account di archiviazione basati su Resource Manager (tipo Premium):
  • Collaboratore
  • Proprietario dei dati del BLOB di archiviazione
• Account di archiviazione classici:
  • Collaboratore account di archiviazione classico
  • Ruolo del servizio dell'operatore della chiave dell'account di archiviazione classico

Azure Site Recovery non tiene traccia delle modifiche delle macchine virtuali di origine all'esterno del sistema operativo di origine. Ad esempio, se si usa la replica di Azure in Azure e si modificano le dimensioni della macchina virtuale di origine, la modifica delle dimensioni della macchina virtuale di origine non viene replicata nella macchina virtuale di destinazione.

• Macchine virtuali di Azure: Site Recovery può replicare qualsiasi carico di lavoro in esecuzione in una macchina virtuale di Azure supportata.
• Macchine virtuali Hyper-V: Site Recovery può proteggere qualsiasi carico di lavoro in esecuzione in una macchina virtuale Hyper-V.
• Server fisici: Site Recovery può proteggere server fisici che eseguono Windows o Linux.
• Macchine virtuali VMware: Site Recovery può proteggere qualsiasi carico di lavoro in esecuzione in una macchina virtuale VMware.

È possibile usare Site Recovery per proteggere la maggior parte dei carichi di lavoro in esecuzione in una macchina virtuale o in un server fisico supportato. Site Recovery fornisce il supporto per la replica compatibile con l'applicazione per consentire il ripristino delle app a uno stato intelligente. Si integra con applicazioni Microsoft come SharePoint, Exchange, Dynamics, SQL Server e Active Directory e collabora strettamente con i principali fornitori, tra cui Oracle, SAP, IBM e Red Hat. Altre informazioni sulla protezione del carico di lavoro.

Sì. Quando si usa Site Recovery per gestire la replica e il failover nelle succursali, si ottiene una gestione unificata e vengono visualizzati tutti i carichi di lavoro delle succursali in una posizione centrale. È possibile eseguire facilmente i failover e amministrare il ripristino di emergenza di tutte le succursali senza abbandonare la sede centrale.

Sì, Site Recovery supporta l'emergenza per le macchine virtuali di Azure tra aree di Azure. Esaminare le domande comuni sul ripristino di emergenza delle macchine virtuali di Azure. Se si vuole eseguire la replica tra due aree di Azure nello stesso continente, usare l'offerta Azure per il ripristino di emergenza di Azure. Non è necessario configurare il server di configurazione/server di elaborazione e le connessioni ExpressRoute.

Sì, Site Recovery supporta il ripristino di emergenza di macchine virtuali VMware locali. Esaminare le domande comuni sul ripristino di emergenza delle macchine virtuali VMware.

Sì, Site Recovery supporta il ripristino di emergenza di macchine virtuali Hyper-V locali. Esaminare le domande comuni per il ripristino di emergenza di macchine virtuali Hyper-V.

Sì, Site Recovery supporta il ripristino di emergenza di server fisici locali che eseguono Windows e Linux in Azure. Informazioni sui requisiti per il ripristino di emergenza in Azure. I server fisici vengono eseguiti come macchine virtuali in Azure dopo il failover. Il failback da Azure a un server fisico locale non è attualmente supportato. È possibile eseguire il failback solo in una macchina virtuale VMware.

No, Azure Site Recovery non supporta lo spostamento dell'insieme di credenziali di Servizi di ripristino in cui sono ospitate macchine virtuali protette.

Azure Site Recovery replica i dati in dischi gestiti o account di archiviazione di Azure su un endpoint pubblico. Tuttavia, la replica può essere eseguita anche tramite VPN da sito a sito. La connettività VPN da sito a sito consente alle organizzazioni di connettere reti esistenti ad Azure o alle reti di Azure tra loro. La VPN da sito a sito avviene tramite il tunneling IPSec su Internet, sfruttando le apparecchiature di rete perimetrali e le appliance di rete perimetrali locali esistenti in Azure, funzionalità native come gateway VPN (Virtual Private Network) di Azure o opzioni di terze parti, ad esempio Check Point CloudIntunerd, Palo Alto NextGen Firewall.

• Connettività privata tramite Internet pubblico a Microsoft Edge
• Insiemi di credenziali dei servizi di ripristino configurati per la sicurezza con endpoint privati
• Replica sulla connessione Rete virtuale privata del cliente
• Transizione facile a "Futuro Stato"
• Nessun contratto di servizio e una latenza potenzialmente superiore
• Richiede la disponibilità di un dispositivo VPN locale

Il nostro partner, Riverbed, fornisce istruzioni dettagliate sull'uso di Azure Site Recovery. Vedere la loro guida alla soluzione.

Sì, è possibile.

• Azure Site Recovery replica i dati in una risorsa di Archiviazione di Azure su un endpoint pubblico. Per usare ExpressRoute per la replica con Site Recovery, è necessario configurare il peering Microsoft o usare un peering pubblico esistente (soluzione deprecata per i nuovi circuiti).
• Il peering Microsoft è il dominio di routing consigliato per la replica.
• La replica è supportata tramite peering privato solo quando gli endpoint privati sono abilitati per l'insieme di credenziali.
• Nel caso in cui si desideri proteggere computer VMware o computer fisici, verificare che i requisiti di rete siano soddisfatti anche per il server di configurazione. Per l'orchestrazione della replica Site Recovery, il server di configurazione richiede la connettività a URL specifici. Non è possibile usare ExpressRoute per questa connettività.
• Dopo che è stato eseguito il failover delle macchine virtuali su una rete virtuale di Azure, è possibile accedere alle macchine virtuali usando la configurazione di peering privato con la rete virtuale di Azure.

L'uso di account di archiviazione come risorsa archiviazione di destinazione non è supportato da Azure Site Recovery. È consigliabile usare invece i dischi gestiti come risorsa di archiviazione di destinazione per le macchine usate. I dischi gestiti supportano solo il tipo di archiviazione con ridondanza locale per la resilienza dei dati.

• Hyper-V: le macchine virtuali Hyper-V possono essere replicate ogni 30 secondi (ad eccezione dell'archiviazione Premium) o cinque minuti.
• Macchine virtuali di Azure, macchine virtuali VMware, server fisici: la frequenza di replica non è rilevante qui. La replica è continua.

No, la replica concatenata o estesa non è supportata. Richiedere questa funzionalità nel forum dei commenti.

Questa operazione non è supportata. Richiedere questa funzionalità nel forum dei commenti.

Questa funzionalità è supportata quando si esegue la replica di macchine virtuali VMware e macchine virtuali Hyper-V in Azure, usando il portale di Azure.

I dischi dinamici sono supportati durante la replica di macchine virtuali Hyper-V e durante la replica di macchine virtuali VMware e computer fisici in Azure. Il disco del sistema operativo deve essere un disco di base.

Sì. Altre informazioni sulla limitazione della larghezza di banda sono disponibili negli articoli seguenti:

• Pianificazione della capacità per la replica di macchine virtuali VMware e server fisici
• Pianificazione della capacità per la replica di macchine virtuali Hyper-V in Azure

Sì. Azure Site Recovery per il sistema operativo Linux supporta script personalizzati delle applicazioni per la coerenza delle app. Lo script personalizzato con pre e post-opzioni viene usato dall'agente di mobilità di Azure Site Recovery durante la coerenza dell'app. Di seguito è riportata la procedura per abilitarlo.

1. Accedere come utente root alla macchina.

2. Passare alla directory del percorso di installazione dell'agente del servizio di mobilità di Azure Site Recovery. Il valore predefinito è "/usr/local/ASR"
   # cd /usr/local/ASR

3. Passare alla directory "VX/scripts" nel percorso di installazione
   # cd VX/scripts

4. Creare uno script della shell Bash denominato "customscript.sh" con autorizzazioni di esecuzione per l'utente root.
   a. Lo script deve supportare le opzioni della riga di comando "--pre" e "--post" (notare i doppi trattini)
   b. Quando lo script viene chiamato con l'opzione pre, bloccherà l'input/output dell'applicazione e, se chiamato con l'opzione post, sbloccherà l'input/output dell'applicazione.
   c. Modello di esempio:
   

   # cat customscript.sh
   

    #!/bin/bash

    if [ $# -ne 1 ]; then
        echo "Usage: $0 [--pre | --post]"
        exit 1
    elif [ "$1" == "--pre" ]; then
        echo "Freezing app IO"
        exit 0
    elif [ "$1" == "--post" ]; then
        echo "Thawed app IO"
        exit 0
    fi

5. Aggiungere i comandi di input/output di blocco e sblocco nei passaggi precedenti e successivi per le applicazioni che richiedono la coerenza delle app. È possibile scegliere di aggiungere un altro script specificandolo e richiamandolo da "customscript.sh" con le opzioni pre e post.

I criteri di replica definiscono le impostazioni per la cronologia di conservazione dei punti di recupero. Definiscono inoltre la frequenza degli snapshot coerenti con l'app. Per impostazione predefinita, Azure Site Recovery crea nuovi criteri di replica con le impostazioni predefinite seguenti:

• Un giorno per la cronologia di conservazione dei punti di ripristino.
• Nessun snapshot coerente con l'app.

Un punto di recupero coerente con l'arresto anomalo del sistema dispone dei dati su disco come se fosse stato rimosso il cavo di alimentazione dal server durante lo snapshot. Non include tutto ciò che era contenuto in memoria quando è stato creato lo snapshot.

La maggior parte delle applicazioni esegue ora correttamente il ripristino da snapshot coerenti con l'arresto anomalo del sistema. Un punto di recupero coerente con l'arresto anomalo del sistema è in genere sufficiente per sistemi operativi senza database e per applicazioni quali file server, server DHCP e server di stampa.

Site Recovery crea un punto di recupero coerente con l'arresto anomalo del sistema ogni 5 minuti.

I punti di recupero coerenti con l'applicazione vengono creati dagli snapshot coerenti con l'applicazione. I punti di recupero coerenti con l'applicazione acquisiscono gli stessi dati di snapshot coerenti con l'arresto anomalo del sistema, oltre a tutti i dati in memoria e a tutte le transazioni in corso.

Per via del loro contenuto aggiuntivo, gli snapshot coerenti con l'applicazione impiegano più tempo di esecuzione e sono i più usati. È consigliabile usare i punti di recupero coerenti con l'applicazione per sistemi operativi e applicazioni di database come SQL Server.

I punti di recupero coerenti con l'applicazione acquisiscono tutti i dati in memoria e in corso. Poiché i punti di recupero acquisiscono tali dati, richiedono framework come Servizio Copia Shadow del volume in Windows per disattivare l'applicazione. Se il processo di acquisizione è frequente, può influire sulle prestazioni quando il carico di lavoro è già elevato. Non è consigliabile usare una frequenza bassa per i punti di recupero coerenti con l'applicazione per carichi di lavoro non di database. Anche per il carico di lavoro del database, 1 ora è sufficiente.

Site Recovery può creare un punto di recupero coerente con l'applicazione con una frequenza minima di 1 ora.

Per comprendere il modo in cui Site Recovery genera i punti di recupero, è possibile esaminare un esempio di criteri di replica. Questo criterio di replica ha un punto di ripristino con una finestra di conservazione di 1 giorno e uno snapshot della frequenza coerente con l'app di 1 ora.

Site Recovery crea un punto di recupero coerente con l'arresto anomalo del sistema ogni 5 minuti. L'utente non può modificare questa frequenza. Per le ultime 2 ore, è possibile scegliere tra 24 punti coerenti con l'arresto anomalo del sistema e 2 punti coerenti con l'app. Con l'avanzamento del tempo, Site Recovery elimina tutti i punti di ripristino oltre le ultime 2 ore e salva un solo punto di ripristino all'ora per un massimo di 24 ore del giorno.

Lo screenshot seguente illustra l'esempio. Nello screenshot:

• Nelle ultime 2 ore sono presenti punti di ripristino con una frequenza di 5 minuti.

• Oltre le ultime 2 ore, Site Recovery mantiene un solo punto di ripristino all'ora.

  

Il punto di ripristino meno recente che è possibile usare è 15 giorni con disco gestito e tre giorni con disco non gestito.

No, Site Recovery mantiene tutti i punti di ripristino precedenti. A seconda dell'intervallo di conservazione dei punti di recupero, Site Recovery sostituisce il punto meno recente solo se genera nuovi punti. A causa del problema, Site Recovery non è in grado di generare nuovi punti di recupero. Fino a quando non sono presenti nuovi punti di ripristino, tutti i punti precedenti rimangono dopo aver raggiunto la finestra di conservazione.

Passare a Insieme di credenziali di Site Recovery>Infrastruttura di Site Recovery>Criteri di replica. Selezionare i criteri da modificare e salvare le modifiche. Qualsiasi modifica si applica anche a tutte le repliche esistenti.

Il primo punto di recupero che viene generato include la copia completa. I punti di recupero successivi includono le modifiche delta.

Sì, se si aumenta il periodo di conservazione da un giorno a tre giorni, Site Recovery salva i punti di ripristino per altri due giorni. Il tempo aggiunto comporta addebiti per l'archiviazione perché saranno presenti 12 punti di ripristino aggiuntivi che devono essere salvati con un aumento del periodo di conservazione da un giorno a tre giorni. Ad esempio, un singolo punto di recupero potrebbe avere variazioni delta di 10 GB con un costo per GB di $0,16 al mese. Gli addebiti aggiuntivi sarebbero di $ 1,60 × 12 al mese.

È possibile accedere alle macchine virtuali di Azure tramite una connessione Internet sicura, tramite una VPN da sito a sito o tramite Azure ExpressRoute. Per poter eseguire la connessione, è necessario completare una serie di operazioni. Altre informazioni.

Azure è progettato nell'ottica della resilienza. Site Recovery è già predisposto per il failover a un data center secondario di Azure in conformità con il contratto di servizio di Azure. In questo caso, Microsoft si assicura che i metadati e gli insiemi di credenziali rimangano nella stessa area geografica selezionata per l'insieme di credenziali.

È possibile attivare un failover non pianificato dal sito secondario. Per eseguire il failover, in Site Recovery non è necessaria la connettività dal sito primario.

Il failover non è automatico. Le operazioni di failover si avviano con un singolo clic nel portale oppure mediante PowerShell per Site Recovery. Il failback è una semplice operazione nel portale di Site Recovery.

Per avviarlo in automatico, è possibile usare Orchestrator o Operations Manager locale per rilevare un errore della macchina virtuale e quindi attivare il failover tramite l'SDK.

• Ulteriori informazioni sui piani di ripristino.
• Altre informazioni sul failover.
• Altre informazioni sul failback di macchine virtuali VMware e server fisici

Sì, è possibile usare il ripristino nel percorso alternativo per eseguire il failback in un host diverso da Azure.

• Per macchine virtuali VMware
• Per macchine virtuali Hyper-V

Dopo il failover di una macchina dalla posizione di origine alla posizione di destinazione, sono disponibili tre opzioni tra cui scegliere. Tutte e tre hanno scopi diversi:

1. Completa migrazione significa che non si tornerà più alla posizione di origine. La migrazione all'area di destinazione è stata completata. Se si fa clic su Completa migrazione, vengono attivati internamente Commit e quindi Disabilita replica.
2. Commit significa che non è la fine del processo di replica. L'elemento di replica insieme a tutta la configurazione rimarrà ed è possibile scegliere Riproteggi in un secondo momento per abilitare la replica delle macchine nell'area di origine.
3. Disabilita replica disabilita la replica e rimuove tutte le configurazioni correlate. Non influirà sulla macchina già esistente nell'area di destinazione.

Sì. È possibile automatizzare i flussi di lavoro di Site Recovery usando l'API REST, PowerShell o Azure SDK. Scenari attualmente supportati per la distribuzione di Site Recovery tramite PowerShell:

• Replicare macchine virtuali Hyper-V nei cloud vmm in Azure PowerShell Resource Manager
• Replicare macchine virtuali Hyper-V senza VMM in Azure PowerShell Resource Manager
• Replicare VMware in Azure con PowerShell Resource Manager

No, il ritiro del modulo AzureRM non influisce sul funzionamento degli aggiornamenti automatici di Site Recovery. Non sono necessarie modifiche per il runbook interno e l'API REST usata sul posto continua a funzionare come previsto con l'account di automazione.

Informazioni sui nuovi aggiornamenti e su come ottenere informazioni sul rollup.

Passaggi successivi

• Leggere la panoramica di Site Recovery