Informazioni sulla configurazione del backup periodico in Azure Service Fabric
La configurazione del backup periodico dei servizi Reliable con stato o dei Reliable Actors è costituita dai passaggi seguenti:
Creazione di criteri di backup: in questa fase vengono creati uno o più criteri di backup, a seconda dei requisiti.
Abilitazione del backup: in questa fase i criteri di backup creati nel passaggio 1 vengono associati alle entità corrispondenti: Applicazione, Servizio o Partizione.
Un criterio di backup è costituito dalle configurazioni seguenti:
- Auto restore on data loss (Ripristino automatico per perdita di dati): specifica se attivare automaticamente il ripristino usando l'ultimo backup disponibile quando la partizione registra un evento di perdita di dati.
Nota
È consigliabile NON impostare il ripristino automatico nei cluster di produzione
Max incremental backups (N. massimo di backup incrementali): definisce il numero massimo di backup incrementali eseguibili tra due backup completi. Max incremental backups (N. massimo di backup incrementali) specifica il limite massimo. Un backup completo può essere eseguito prima del raggiungimento del numero di backup incrementali specificato se si verifica una delle situazioni seguenti:
La replica non ha mai eseguito un backup completo dopo essere diventata primaria.
Alcuni record di log successivi all'ultimo backup sono stati troncati.
La replica ha superato il limite specificato in MaxAccumulatedBackupLogSizeInMB.
Pianificazione backup: cadenza o frequenza di esecuzione dei backup periodici. È possibile pianificare l'esecuzione di backup a intervalli specificati o con un orario fisso ogni giorno o ogni settimana.
Frequency-based backup schedule (Pianificazione backup basata sulla frequenza): questo tipo di pianificazione può essere usato quando è necessario eseguire il backup dei dati a intervalli fissi. L'intervallo di tempo desiderato tra due backup successivi può essere definito usando il formato ISO 8601. La pianificazione backup basata sulla frequenza supporta la risoluzione di intervalli fino a un minuto.
{ "ScheduleKind": "FrequencyBased", "Interval": "PT10M" }
Time-based backup schedule (Pianificazione backup basata su tempo): questo tipo di pianificazione può essere usato quando è necessario eseguire il backup dei dati in orari specifici ogni giorno o ogni settimana. Il tipo di frequenza di pianificazione può essere giornaliero o settimanale.
Pianificazione backup basata sul tempo Giornaliera: questo tipo di pianificazione deve essere usato quando è necessario eseguire il backup dei dati ogni giorno a orari specifici. Per fare ciò impostare
ScheduleFrequencyType
su Giornaliera e impostareRunTimes
sull'elenco di orari della giornata desiderati, in formato ISO 8601. La data specificata insieme all'ora viene ignorata. Ad esempio0001-01-01T18:00:00
rappresenta le 18:00 di ogni giorno e la parte della data 0001-01-01 viene ignorata. L'esempio seguente visualizza la configurazione che attiva un backup giornaliero alle9:00 e alle 18:00 di ogni giorno.{ "ScheduleKind": "TimeBased", "ScheduleFrequencyType": "Daily", "RunTimes": [ "0001-01-01T09:00:00Z", "0001-01-01T18:00:00Z" ] }
Pianificazione backup basata sul tempo Settimanale: questo tipo di pianificazione deve essere usato quando è necessario eseguire il backup dei dati a orari specifici di un giorno. Per fare ciò impostare
ScheduleFrequencyType
su Settimanale, quindi impostareRunDays
sull'elenco dei giorni della settimana in cui va attivato il backup e impostareRunTimes
sull'elenco di orari della giornata desiderati, in formato ISO 8601. La data specificata insieme all'ora viene ignorata. Elenco dei giorni della settimana in cui attivare il backup periodico. L'esempio seguente visualizza una configurazione che attiva il backup giornaliero alle 9:00 e alle 18.00 ogni giorno da lunedì a venerdì.{ "ScheduleKind": "TimeBased", "ScheduleFrequencyType": "Weekly", "RunDays": [ "Monday", "Tuesday", "Wednesday", "Thursday", "Friday" ], "RunTimes": [ "0001-01-01T09:00:00Z", "0001-01-01T18:00:00Z" ] }
Archivio backup: specifica il percorso in cui caricare i backup. La destinazione di archiviazione può essere l'archivio BLOB di Azure o una condivisione di file.
Archivio BLOB di Azure con identità gestita: questo tipo di archiviazione deve essere selezionato quando è necessario archiviare i backup generati in Azure. Questo tipo di archiviazione può essere usato sia dai cluster autonomi che da quelli basati sul cloud. La descrizione di questo tipo di archiviazione richiede il parametro BlobServiceUri e il nome del contenitore in cui devono essere caricati i backup. Se il contenitore con il nome specificato non è disponibile, viene creato durante il caricamento di un backup. Sostituire
account-name
con il nome dell'account di archiviazione.{ "StorageKind": "ManagedIdentityAzureBlobStore", "FriendlyName": "AzureMI_storagesample", "BlobServiceUri": "https://<account-name>.blob.core.windows.net", "ContainerName": "backup-container", "ManagedIdentityType": "VMSS", "ManagedIdentityClientId": "<Client-Id of User-Assigned MI>" }
[NOTA] Usare il parametro facoltativo
ManagedIdentityClientId
con l'ID client dell'identità gestita assegnata dall'utente in caso in cui alla risorsa siano state assegnate più identità gestite assegnate dall'utente o siano presenti identità gestite assegnate sia dal sistema che dall’utente e per impostazione predefinita sia necessario usare l’identità gestita assegnata dall'utente. In caso contrario, è possibile ignorare questo parametro.Seguire la procedura per l'assegnazione di identità gestite in una risorsa di Azure:
Abilitare l'identità gestita assegnata dal sistema o dall'utente nel set di scalabilità di macchine virtuali Configurare le identità gestite nel set di scalabilità di macchine virtuali
Assegnare il ruolo all'identità gestita del set di scalabilità di macchine virtuali nell'account di archiviazione Assegnare ruoli di Azure usando il portale di Azure - Controllo degli accessi in base al ruolo di Azure
- Ruolo Collaboratore ai dati dei BLOB di archiviazione (come minimo)
Archivio BLOB di Azure con ConnectionString: questo tipo di archiviazione deve essere selezionato quando è necessario archiviare i backup generati in Azure. Questo tipo di archiviazione può essere usato sia dai cluster autonomi che da quelli basati sul cloud. La descrizione di questo tipo di archiviazione richiede la stringa di connessione e il nome del contenitore in cui devono essere caricati i backup. Se il contenitore con il nome specificato non è disponibile, viene creato durante il caricamento di un backup.
{ "StorageKind": "AzureBlobStore", "FriendlyName": "Azure_storagesample", "ConnectionString": "<Put your Azure blob store connection string here>", "ContainerName": "backup-container" }
Nota
Il servizio di backup/ripristino non funziona con ConnectionString di Archiviazione di Azure v1 e non è consigliato nell'ambiente di produzione perché si accede direttamente alla risorsa senza autenticazione utente
Condivisione file: questo tipo di archiviazione deve essere selezionato per i cluster autonomi quando è necessario archiviare i dati di backup in locale. La descrizione di questo tipo di archiviazione richiede il percorso di condivisione file in cui devono essere caricati i backup. L'accesso alla condivisione file può essere configurato usando una delle seguenti opzioni
Autenticazione di Windows integrata: in cui l'accesso alla condivisione file è consentito a tutti i computer appartenenti al cluster Service Fabric. In questo caso impostare i campi seguenti per configurare l'archiviazione di backup basata sulla condivisione file.
{ "StorageKind": "FileShare", "FriendlyName": "Sample_FileShare", "Path": "\\\\StorageServer\\BackupStore" }
Protezione della condivisione file con nome utente e password: in cui l'accesso alla condivisione file è consentito a utenti specifici. La specifica di archiviazione basata sulla condivisione file consente anche di specificare un nome utente secondario e una password secondaria come credenziali di fallback, nel caso in cui l'autenticazione con il nome utente primario e la password primaria abbia esito negativo. In questo caso impostare i campi seguenti per configurare l'archiviazione di backup basata sulla condivisione file.
{ "StorageKind": "FileShare", "FriendlyName": "Sample_FileShare", "Path": "\\\\StorageServer\\BackupStore", "PrimaryUserName": "backupaccount", "PrimaryPassword": "<Password for backupaccount>", "SecondaryUserName": "backupaccount2", "SecondaryPassword": "<Password for backupaccount2>" }
Nota
Verificare che l'affidabilità di archiviazione soddisfi o superi i requisiti di affidabilità dei dati di backup.
- Criteri di conservazione: specifica i criteri per conservare i backup nella risorsa di archiviazione configurata. Sono supportati solo i criteri di conservazione di base.
Criteri di conservazione di base: questi criteri di conservazione consentono di garantire l'utilizzo ottimale dell'archiviazione rimuovendo i file di backup non più necessari. Specificare
RetentionDuration
per impostare l'intervallo di tempo in cui i backup devono essere conservati nella risorsa di archiviazione.MinimumNumberOfBackups
è un parametro facoltativo che può essere specificato per assicurarsi che venga sempre mantenuto il numero specificato di backup indipendentemente daRetentionDuration
. L'esempio seguente illustra la configurazione che consente di conservare i backup per 10 giorni e non consente che il numero di backup scenda a meno di 20.{ "RetentionPolicyType": "Basic", "RetentionDuration": "P10D", "MinimumNumberOfBackups": 20 }
Dopo aver definito i criteri di backup in modo da soddisfare i requisiti per il backup dei dati, è necessario associare i criteri di backup a un'applicazione, a un servizio o a una partizione.
Nota
Prima di abilitare il backup, assicurarsi che non siano in corso aggiornamenti dell'applicazione
In Service Fabric la relazione tra applicazione, servizio e partizioni è gerarchica, come illustrato in Modello applicativo. Il criterio di backup può essere associato a un'applicazione, un servizio o una partizione nella gerarchia. I criteri di backup si propagano gerarchicamente al livello successivo. Se ad esempio è presente un solo set di criteri di backup associato a un'applicazione, tutte le partizioni con stato appartenenti a tutti i Reliable Service con stato e ai Reliable Actors dell'applicazione vengono sottoposte a backup usando i criteri di backup. Analogamente, se i criteri di backup sono associati a un Reliable Service con stato, tutte le partizioni del servizio vengono sottoposte a backup usando i criterio di backup.
In un determinato scenario è possibile che il backup dei dati con la stessa pianificazione sia idoneo per tutti i servizi dell'applicazione ad eccezione di servizi specifici, che richiedono ad esempio una pianificazione più frequente o un backup in un account di archiviazione o una condivisione di file diversa. Per la risoluzione di queste situazioni, il servizio di ripristino del backup dispone di un'opzione per eseguire l'override del criterio propagato a livello del servizio e della partizione. Quando il criterio di backup è associato a un servizio o una partizione, esegue l'override del criterio di backup propagato, se presente.
Questo esempio usa una configurazione con due applicazioni, MyApp_A e MyApp_B. L'applicazione MyApp_A contiene due servizi Reliable Service con stato, SvcA1e SvcA3 e un servizio Reliable Actor, ActorA2. SvcA1 contiene tre partizioni, mentre ActorA2 e SvcA3 contengono due partizioni ciascuno. L'applicazione MyApp_B contiene tre servizi Reliable con stato: SvcB1, SvcB2 e SvcB3. _SvcB1 e SvcB2 contengono due partizioni ciascuno, mentre SvcB3 contiene tre partizioni.
Si supponga che i requisiti di backup dei dati di queste applicazioni siano i seguenti
MyApp_A
Creare un backup giornaliero dei dati per tutte le partizioni di tutti i servizi Reliable con stato e i Reliable Actors appartenenti all'applicazione. Caricare i dati di backup nella posizione BackupStore1.
Uno dei servizi, SvcA3, richiede il backup dei dati ogni ora.
Il volume dei dati nella partizione SvcA1_P2 è superiore a quello previsto e i dati di backup corrispondenti devono essere archiviati in un'altra posizione di archiviazione, BackupStore2.
MyApp_B
Creare il backup dei dati ogni domenica alle ore 8:00 per tutte le partizioni del servizio SvcB1. Caricare i dati di backup nella posizione BackupStore1.
Creare il backup dei dati ogni giorno alle ore 8:00 per la partizione SvcB2_P1. Caricare i dati di backup nella posizione BackupStore1.
Per soddisfare questi requisiti di backup dei dati, vengono creati i criteri di backup da BP_1 a BP_5 e il backup viene implementato come indicato di seguito.
MyApp_A
Creare un criterio di backup BP_1 con pianificazione del backup basata sulla frequenza (in cui la frequenza è impostata su 24 ore) e archiviazione del backup configurata per l'uso del percorso di archiviazione BackupStore1. Abilitare questo criterio per l'applicazione MyApp_A usando l'API Enable Application Backup. Questa azione abilita il backup dei dati usando il criterio di backup BP_1 per tutte le partizioni di servizi Reliable con stato e Reliable Actors appartenenti all'applicazione MyApp_A.
Creare un criterio di backup BP_2 con pianificazione del backup basata sulla frequenza (in cui la frequenza è impostata su 1 ora) e archiviazione del backup configurata per l'uso del percorso di archiviazione BackupStore1. Abilitare questo criterio per il servizio SvcA3 usando l'API Enable Service Backup. Questa azione esegue l'override del criterio propagato BP_1 abilitando esplicitamente il criterio di backup BP_2 per tutte le partizioni del servizio SvcA3: per queste partizioni viene usato il criterio di backup BP_2.
Creare un criterio di backup BP_3 con pianificazione del backup basata sulla frequenza (in cui la frequenza è impostata su 24 ore) e archiviazione del backup configurata per l'uso del percorso di archiviazione BackupStore2. Abilitare questo criterio per la partizione SvcA1_P2 usando l'API Enable Partition Backup. Questa azione esegue l'override del criterio propagato BP_1 e abilita in modo esplicito il criterio di backup BP_3 per la partizione SvcA1_P2.
MyApp_B
Creare il criterio di backup BP_4 con pianificazione di backup basata su tempo, tipo di frequenza di pianificazione impostato su Settimanale, giorno di esecuzione impostato sulla domenica e orario di esecuzione impostato sulle 8:00. Archivio di backup configurato per l'uso del percorso di archiviazione BackupStore1. Abilitare questo criterio per il servizio SvcB1 usando l'API Enable Service Backup. Questa azione abilita il backup dei dati usando il criterio di backup BP_4 per tutte le partizioni del servizio SvcB1.
Creare il criterio di backup BP_5 con pianificazione di backup basata su tempo, tipo di frequenza di pianificazione impostato su Giornaliera, giorno di esecuzione impostato sulla domenica e orario di esecuzione impostato sulle 8:00. Archivio di backup configurato per l'uso del percorso di archiviazione BackupStore1. Abilitare questo criterio per la partizione SvcB2_P1 usando l'API Enable Partition Backup. Questa azione abilita il backup dei dati usando il criterio di backup BP_5 per la partizione SvcB2_P1.
Il diagramma seguente visualizza i criteri di backup abilitati in modo esplicito e i criteri di backup propagati.
È possibile disabilitare i criteri di backup quando non è necessario eseguire il backup dei dati. Un criterio di backup abilitato per un'applicazione può essere disabilitato solo nella stessa applicazione usando l'API Disable Application Backup; un criterio di backup abilitato per un servizio può essere disabilitato nello stesso servizio usando l'API Disable Service Backup; un criterio di backup abilitato per una partizione può essere disabilitato nella stessa partizione usando l'API Disable Partition Backup.
La disabilitazione di un criterio di backup per un'applicazione arresta tutti i backup dei dati periodici che si verificano in seguito alla propagazione del criterio di backup alle partizioni del servizio Reliable con stato o alle partizioni Reliable Actor.
La disabilitazione di un criterio di backup per un servizio arresta tutti i backup dei dati periodici che si verificano in seguito alla propagazione del criterio di backup alle partizioni del servizio.
La disabilitazione di un criterio di backup per una partizione arresta tutti i backup periodici dei dati eseguiti nella partizione in base a tale criterio.
Durante la disabilitazione del backup per un'entità (applicazione/servizio/partizione) è possibile impostare
CleanBackup
su true per eliminare tutti i backup nella risorsa di archiviazione configurata.{ "CleanBackup": true }
Nota
Prima di disabilitare il backup, assicurarsi che non siano in corso aggiornamenti dell'applicazione
In determinati casi può risultare necessario sospendere temporaneamente il backup periodico dei dati. In queste situazioni, a seconda delle esigenze, è possibile usare l'API di sospensione del backup a livello di applicazione, servizio o partizione. La sospensione del backup periodico è transitiva per il sottoalbero della gerarchia dell'applicazione dal punto in cui viene applicata.
Se la sospensione viene implementata in un'applicazione usando l'API Suspend Application Backup, il backup periodico dei dati viene sospeso per tutti i servizi e le partizioni sotto tale applicazione.
Se la sospensione viene implementata in un servizio usando l'API Suspend Service Backup, il backup periodico dei dati viene sospeso per tutte le partizioni sotto tale servizio.
Se la sospensione viene implementata in una partizione usando l'API Suspend Partition Backup, il backup periodico dei dati viene sospeso per tutti i dati inclusi in tale partizione.
Quando la sospensione non è più necessaria è possibile ripristinare il backup periodico dei dati usando le rispettive API di ripresa del backup. Il backup periodico deve essere ripresto nella stessa applicazione, servizio o partizione in cui è stato sospeso.
Se la sospensione è stata applicata in un'applicazione, il backup deve essere ripreso usando l'API Resume Application Backup.
Se la sospensione è stata applicata in un servizio, il backup deve essere ripreso usando l'API Resume Service Backup.
Se la sospensione è stata applicata in una partizione, il backup deve essere ripreso usando l'API Resume Partition Backup.
È opportuno usare la funzionalità di disabilitazione dei backup quando i backup non sono più necessari per un'applicazione, un servizio o una partizione specifica. È possibile anche richiamare una richiesta di disabilitazione dei backup insieme al parametro di pulizia dei backup per essere certi che vengano eliminati anche tutti i backup esistenti. È opportuno invece usare la funzionalità di sospensione nei casi in cui si intende disattivare temporaneamente i backup, ad esempio quando il disco locale è pieno o il caricamento di una copia di backup non riesce a causa di un problema di rete e così via.
Mentre la disabilitazione può essere richiamata solo a un livello precedentemente abilitato in modo esplicito per il backup, la sospensione può essere applicata a qualsiasi livello attualmente abilitato per il backup, direttamente o tramite ereditarietà/gerarchia. Se, ad esempio, il backup viene abilitato al livello di un'applicazione, è possibile richiamare la disabilitazione solo al livello dell'applicazione, mentre la sospensione può essere richiamata anche per qualsiasi servizio o partizione presente nell'applicazione.
La partizione del servizio potrebbe perdere dati a causa di errori imprevisti. Ad esempio, il disco per due su tre repliche per una partizione, inclusa la replica primaria, viene danneggiato o cancellato.
Quando Service Fabric rileva che nella partizione si verifica la perdita di dati, chiama il metodo di interfaccia OnDataLossAsync
per la partizione e prevede che la partizione esegua l'azione necessaria per bloccare la perdita di dati. In questa situazione, se il flag AutoRestoreOnDataLoss
del criterio di backup in vigore nella partizione è impostato su true
il ripristino viene attivato automaticamente usando il backup disponibile più recente per la partizione.
Nota
È consigliabile NON impostare il ripristino automatico nei cluster di produzione
API diverse consentono di ottenere informazioni di configurazione del backup a livello di applicazione, servizio e partizione. Le API sono rispettivamente Get Application Backup Configuration Info, Get Service Backup Configuration Info e Get Partition Backup Configuration Info. In generale queste API restituiscono il criterio di backup applicabile, l'ambito di applicazione del criterio e i dettagli della sospensione del backup. Segue una breve descrizione dei risultati restituiti da queste API.
Informazioni sulla configurazione del backup di un’applicazione: vengono specificati i dettagli dei criteri di backup applicati all'applicazione e di tutti i criteri sottoposti a override nei servizi e nelle partizioni appartenenti all'applicazione. Sono incluse anche informazioni di sospensione per l'applicazione e i servizi e le partizioni corrispondenti.
Informazioni sulla configurazione del backup di un servizio: vengono specificati i dettagli dei criteri di backup in vigore nel servizio, l'ambito in cui i criteri sono stati applicati e tutti i criteri sottoposti a override nelle partizioni del servizio. Include anche le informazioni di sospensione per il servizio e le relative partizioni.
Get Partition Backup Configuration Info: specifica i dettagli del criterio di backup in vigore nella partizione e l'ambito in cui il criterio è stato applicato. Include anche le informazioni di sospensione per le partizioni.
È possibile elencare i backup disponibili tramite l'API Get Backup List. La chiamata dell'API restituisce informazioni su tutti i backup disponibili nell'archivio di backup, configurato nei criteri di backup applicabili. Sono disponibili diverse varianti dell'API, che consentono di elencare i backup disponibili appartenenti a un'applicazione, un servizio o una partizione. Queste API supportano il recupero del backup disponibile più recente di tutte le partizioni applicabili o il filtraggio dei backup in base alla data di inizio e alla data fine.
Le API supportano anche l'impaginazione dei risultati: quando il parametro MaxResults è impostato su un numero intero positivo diverso da zero, l'API restituisce un numero massimo di voci informative sul backup pari a MaxResults. Se il numero di voci informative sul backup è superiore al valore di MaxResults viene restituito un token di continuazione. Il parametro del token di continuazione valido può essere usato per ottenere il set di risultati successivo. Quando il valore del token di continuazione valido viene passato alla chiamata successiva dell'API, l'API restituisce il set di risultati successivo. Se vengono restituiti tutti i risultati disponibili, la risposta non include un token di continuazione.
Di seguito sono elencate informazioni concise sulle varianti supportate.
Get Application Backup List: restituisce l'elenco dei backup disponibili per ogni partizione appartenente a un'applicazione Service Fabric specifica.
Get Service Backup List: restituisce l'elenco dei backup disponibili per ogni servizio appartenente a un'applicazione Service Fabric specifica.
Get Partition Backup List: restituisce l'elenco dei backup disponibili per la partizione specificata.