Condividi tramite

Eseguire il backup di database PostgreSQL usando Azure PowerShell

Questo articolo descrive come eseguire il backup di Database di Azure per PostgreSQL usando Azure PowerShell. È anche possibile configurare il backup usando il portale di Azure, l'interfaccia della riga di comando di Azure e l'API REST per i database PostgreSQL.

Altre informazioni sugli scenari supportati e sulle domande frequenti per il backup di database PostgreSQL in Database di Azure per PostgreSQL.

Creare una cassaforte di backup

Una cassa di backup è un'entità di archiviazione in Azure. Archivia i dati di backup per vari nuovi carichi di lavoro supportati da Backup di Azure, ad esempio i server di Database di Azure per PostgreSQL, i dischi di Azure e i BLOB di Azure. I vault di backup aiutano a organizzare i dati di backup, minimizzando il sovraccarico di gestione. Gli insiemi di backup si basano sul modello Azure Resource Manager, che offre funzionalità avanzate per proteggere i dati di backup.

Prima di creare un archivio di Backup, scegli la ridondanza di archiviazione dei dati all'interno di questo archivio. Procedere quindi con la creazione dell'insieme di credenziali di Backup con la ridondanza di archiviazione e il percorso.

In questo articolo viene creato un insieme di credenziali di backup denominato TestBkpVault, nell'area westus, all'interno del gruppo di risorse testBkpVaultRG. Usare il comando New-AzDataProtectionBackupVault per creare un insieme di credenziali di Backup. Scopri di più sulla creazione di un archivio di backup.

$storageSetting = New-AzDataProtectionBackupVaultStorageSettingObject -Type LocallyRedundant/GeoRedundant -DataStoreType VaultStore
New-AzDataProtectionBackupVault -ResourceGroupName testBkpVaultRG -VaultName TestBkpVault -Location westus -StorageSetting $storageSetting
$TestBkpVault = Get-AzDataProtectionBackupVault -VaultName TestBkpVault
$TestBKPVault | fl
ETag                :
Id                  : /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx/resourceGroups/testBkpVaultRG/providers/Microsoft.DataProtection/backupVaults/TestBkpVault
Identity            : Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.Api20210201Preview.DppIdentityDetails
IdentityPrincipalId :
IdentityTenantId    :
IdentityType        :
Location            : westus
Name                : TestBkpVault
ProvisioningState   : Succeeded
StorageSetting      : {Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.Api20210201Preview.StorageSetting}
SystemData          : Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.Api20210201Preview.SystemData
Tag                 : Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.Api20210201Preview.DppTrackedResourceTags
Type                : Microsoft.DataProtection/backupVaults

Creare una politica di backup

Dopo aver creato una cassaforte, è possibile creare criteri di backup per proteggere i database PostgreSQL. È anche possibile creare criteri di backup per i database PostgreSQL usando l'API REST.

Informazioni sui criteri di backup di PostgreSQL

Mentre il backup su disco offre più backup al giorno e il backup BLOB è un backup continuo senza trigger, il backup di PostgreSQL offre la protezione dell'archivio. È possibile spostare i dati di backup inizialmente inviati all'insieme di credenziali nel livello archivio in base a una regola definita o a un ciclo di vita.

In questo contesto, la gerarchia seguente consente di comprendere l'oggetto criteri di backup per PostgreSQL:

  • Norma della politica
    • Regola di backup
      • Parametro di backup
        • Tipo di backup (in questo caso backup completo del database)
        • Archivio dati iniziale (in cui inizialmente i backup atterrano)
        • Trigger (modalità di attivazione del backup)
          • Calendario
          • Criteri di assegnazione di tag predefiniti (un tag predefinito che collega tutti i backup pianificati alla regola di conservazione)
    • Regola di conservazione predefinita (regola applicata a tutti i backup, per impostazione predefinita, nell'archivio dati iniziale)

L'oggetto criteri definisce i tipi di backup attivati, il modo in cui vengono attivati (tramite una pianificazione), i tag con cui vengono contrassegnati, dove vengono inseriti (un archivio dati) e il ciclo di vita dei dati in un archivio dati.

L'oggetto PowerShell predefinito per PostgreSQL indica di attivare un backup completo ogni settimana. I backup arrivano nell'insieme di credenziali, dove restano archiviati per tre mesi.

Se si vuole aggiungere il livello archivio ai criteri, è necessario decidere quando i dati verranno spostati dall'insieme di credenziali all'archivio, per quanto tempo rimarranno nell'archivio e quali backup pianificati devono essere contrassegnati come archiviabili. È necessario aggiungere una regola di conservazione che definisca il ciclo di vita dei dati di backup dall'archivio dati dell'insieme di credenziali all'archivio dati di archiviazione. La regola di conservazione definisce anche per quanto tempo i dati di backup rimarranno nell'archivio dati di archiviazione. È quindi necessario aggiungere un tag che contrassegna i backup pianificati come idonei per l'archiviazione.

L'oggetto PowerShell risultante è il seguente:

  • Norma della politica
    • Regola di backup
      • Parametro di backup
        • Tipo di backup (in questo caso backup completo del database)
        • Archivio dati iniziale (in cui inizialmente i backup atterrano)
        • Trigger (modalità di attivazione del backup)
          • Calendario
          • Criteri di assegnazione di tag predefiniti (un tag predefinito che collega tutti i backup pianificati alla regola di conservazione)
          • Nuovi criteri di assegnazione di tag per la nuova regola di conservazione con lo stesso nome
    • Regola di conservazione predefinita (regola applicata a tutti i backup, per impostazione predefinita, nell'archivio dati iniziale)
    • Nuova regola di conservazione
      • Ciclo vitale
        • Archivio dati di origine
        • Periodo di tempo per l'eliminazione nell'archivio dati di origine
        • Copiare nell'archivio dati di destinazione

Recuperare il modello di criteri

Per comprendere i componenti interni di un criterio di backup per il backup del database PostgreSQL, recuperare il modello di criteri usando il Get-AzDataProtectionPolicyTemplate comando . Questo comando restituisce il modello di criteri predefinito per un tipo di origine dati. Usare questo modello di criterio per creare un nuovo criterio.

$policyDefn = Get-AzDataProtectionPolicyTemplate -DatasourceType AzureDatabaseForPostgreSQL
$policyDefn | fl


DatasourceType : {Microsoft.DBforPostgreSQL/servers/databases}
ObjectType     : BackupPolicy
PolicyRule     : {BackupWeekly, Default}

$policyDefn.PolicyRule | fl


BackupParameter           : Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.Api20210701.AzureBackupParams
BackupParameterObjectType : AzureBackupParams
DataStoreObjectType       : DataStoreInfoBase
DataStoreType             : VaultStore
Name                      : BackupWeekly
ObjectType                : AzureBackupRule
Trigger                   : Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.Api20210701.ScheduleBasedTriggerCo
                            ntext
TriggerObjectType         : ScheduleBasedTriggerContext

IsDefault  : True
Lifecycle  : {Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.Api20210701.SourceLifeCycle}
Name       : Default
ObjectType : AzureRetentionRule

Il modello di criteri è costituito da un trigger (che determina quali attivano il backup) e un ciclo di vita (che decide quando eliminare, copiare o spostare il backup). In un backup del database PostgreSQL il valore predefinito per il trigger è un trigger settimanale pianificato (un backup ogni sette giorni). Ogni backup viene conservato per tre mesi.

 $policyDefn.PolicyRule[0].Trigger | fl


ObjectType                    : ScheduleBasedTriggerContext
ScheduleRepeatingTimeInterval : {R/2021-08-22T02:00:00+00:00/P1W}
ScheduleTimeZone              : UTC
TaggingCriterion              : {Default}

$policyDefn.PolicyRule[1].Lifecycle | fl


DeleteAfterDuration        : P3M
DeleteAfterObjectType      : AbsoluteDeleteOption
SourceDataStoreObjectType  : DataStoreInfoBase
SourceDataStoreType        : VaultStore
TargetDataStoreCopySetting : {}

Modificare il modello di policy

Modificare la pianificazione

Il modello di criteri predefinito prevede un backup una volta alla settimana. È possibile modificare la pianificazione del backup in modo che venga eseguita più giorni alla settimana. Per modificare la pianificazione, usare il Edit-AzDataProtectionPolicyTriggerClientObject comando .

Nell'esempio seguente viene modificato il backup settimanale in domenica, mercoledì e venerdì di ogni settimana. La matrice delle date di pianificazione indica le date, e i giorni della settimana corrispondenti a queste date vengono considerati come tali. È anche necessario indicare che queste pianificazioni devono essere ripetute ogni settimana. L'intervallo di pianificazione è 1 quindi e il tipo di intervallo è Weekly.

$schDates = @(
  (
    (Get-Date -Year 2021 -Month 08 -Day 15 -Hour 22 -Minute 0 -Second 0)
  ), 
  (
    (Get-Date -Year 2021 -Month 08 -Day 18 -Hour 22 -Minute 0 -Second 0)
  ),
  (
    (Get-Date -Year 2021 -Month 08 -Day 20 -Hour 22 -Minute 0 -Second 0)
  )
)
$trigger = New-AzDataProtectionPolicyTriggerScheduleClientObject -ScheduleDays $schDates -IntervalType Weekly -IntervalCount 1 
Edit-AzDataProtectionPolicyTriggerClientObject -Schedule $trigger -Policy $policyDefn

Aggiungere una nuova regola di conservazione

Se si vuole aggiungere la protezione dell'archivio, è necessario modificare il modello di criteri.

Il modello predefinito ha un ciclo di vita per l'archivio dati iniziale nella regola di conservazione predefinita. In questo scenario, la regola specifica di eliminare i dati di backup dopo tre mesi. È necessario aggiungere una nuova regola di conservazione che definisce quando i dati vengono spostati nell'archivio dati di archiviazione. Ovvero, i dati di backup vengono prima copiati nell'archivio dati e quindi eliminati nell'archivio dati del vault.

Inoltre, la regola deve definire per quanto tempo conservare i dati nel datastore di archiviazione. Per creare nuovi cicli di vita, usare il New-AzDataProtectionRetentionLifeCycleClientObject comando . Per associare tali cicli di vita a regole nuove o esistenti, usare il Edit-AzDataProtectionPolicyRetentionRuleClientObject comando .

Nell'esempio seguente viene creata una nuova regola di conservazione denominata Monthly. In questa regola, il primo backup riuscito di ogni mese viene conservato nel vault per sei mesi, spostato nel livello di archivio e mantenuto nel livello di archivio per 24 mesi.

$VaultToArchiveLifeCycle = New-AzDataProtectionRetentionLifeCycleClientObject -SourceDataStore VaultStore -SourceRetentionDurationType Months -SourceRetentionDurationCount 6 -TargetDataStore ArchiveStore -CopyOption CopyOnExpiryOption

$OnArchiveLifeCycle = New-AzDataProtectionRetentionLifeCycleClientObject -SourceDataStore ArchiveStore -SourceRetentionDurationType Months -SourceRetentionDurationCount 24

Edit-AzDataProtectionPolicyRetentionRuleClientObject -Policy $policyDefn -Name Monthly -LifeCycles $VaultToArchiveLifeCycle, $OnArchiveLifeCycleLifeCycle -IsDefault $false

Aggiungere un tag e i criteri pertinenti

Dopo aver creato una regola di conservazione, è necessario creare un tag corrispondente nella Trigger proprietà dei criteri di backup. Per creare nuovi criteri di assegnazione di tag, usare il New-AzDataProtectionPolicyTagCriteriaClientObject comando . Per aggiornare il tag esistente o creare un nuovo tag, usare il comando Edit-AzDataProtectionPolicyTagClientObject .

Nell'esempio seguente viene creato un nuovo tag insieme ai criteri, ovvero il primo backup riuscito del mese. Il tag ha lo stesso nome della regola di conservazione corrispondente da applicare.

In questo esempio i criteri di tag sono denominati Monthly:

$tagCriteria = New-AzDataProtectionPolicyTagCriteriaClientObject -AbsoluteCriteria FirstOfMonth
Edit-AzDataProtectionPolicyTagClientObject -Policy $policyDefn -Name Monthly -Criteria $tagCriteria

Se la pianificazione è costituito da più backup alla settimana (ogni domenica, mercoledì e giovedì, come specificato nell'esempio precedente) e si desidera archiviare i backup di domenica e venerdì, è possibile modificare i criteri di assegnazione di tag come indicato di seguito:

$tagCriteria = New-AzDataProtectionPolicyTagCriteriaClientObject -DaysOfWeek @("Sunday", "Friday")
Edit-AzDataProtectionPolicyTagClientObject -Policy $policyDefn -Name Monthly -Criteria $tagCriteria

Creare un nuovo criterio di backup PostgreSQL

Dopo aver modificato il modello in base ai requisiti, usare il New-AzDataProtectionBackupPolicy comando per creare un criterio usando il modello modificato:

$polOss = New-AzDataProtectionBackupPolicy -ResourceGroupName testBkpVaultRG -VaultName TestBkpVault -Name "TestOSSPolicy" -Policy $policyDefn

Configurare il backup

Dopo aver creato l'archivio e i criteri, è necessario considerare tre aspetti fondamentali per eseguire il backup di un database PostgreSQL in Database di Azure per PostgreSQL.

Informazioni sulle entità chiave

Database PostGreSQL di cui eseguire il backup

Recuperare l'ID resource manager del database PostgreSQL di cui eseguire il backup. Questo ID funge da identificatore del database. L'esempio seguente usa un database denominato empdb11 nel server testposgresqlPostgreSQL , presente nel gruppo ossrg di risorse in una sottoscrizione diversa:

$ossId = "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx/resourcegroups/ossrg/providers/Microsoft.DBforPostgreSQL/servers/archive-postgresql-ccy/databases/empdb11"

Insieme di credenziali delle chiavi

Il servizio Backup di Azure non archivia il nome utente e la password per connettersi al database PostgreSQL. L'amministratore del backup effettua invece il seeding delle chiavi nell'insieme di credenziali delle chiavi. Il servizio Backup di Azure accede quindi all'insieme di credenziali, legge le chiavi e accede al database. Prendere nota dell'identificatore segreto della chiave pertinente.

$keyURI = "https://testkeyvaulteus.vault.azure.net/secrets/ossdbkey"

Insieme di credenziali per il backup

È necessario connettere il Vault di backup al server PostgreSQL e quindi accedere al database tramite le chiavi presenti nel Vault delle chiavi. Quindi, la cassaforte di Backup richiede l'accesso al server PostgreSQL e alla cassaforte delle chiavi. L'accesso viene concesso all'identità del servizio gestita dell'insieme di credenziali per il backup.

Leggi delle autorizzazioni appropriate che è necessario concedere all'identità gestita del vault di backup nel server PostgreSQL e in Azure Key Vault, in cui vengono archiviate le chiavi del database.

Preparare la richiesta

Dopo aver impostato tutte le autorizzazioni pertinenti, eseguire la configurazione del backup in due passaggi:

  1. Preparare la richiesta usando il vault pertinente, i criteri e il database PostgreSQL nel comando Initialize-AzDataProtectionBackupInstance.
  2. Inviare la richiesta per eseguire il backup del database usando il New-AzDataProtectionBackupInstance comando .
$instance = Initialize-AzDataProtectionBackupInstance -DatasourceType AzureDatabaseForPostgreSQL -DatasourceLocation $TestBkpvault.Location -PolicyId $polOss[0].Id -DatasourceId $ossId -SecretStoreURI $keyURI -SecretStoreType AzureKeyVault
ConvertTo-Json -InputObject $instance -Depth 4 
New-AzDataProtectionBackupInstance -ResourceGroupName "testBkpVaultRG" -VaultName $TestBkpVault.Name -BackupInstance $instance

Name                        Type                                         BackupInstanceName
----                        ----                                          ------------------
ossrg-empdb11       Microsoft.DataProtection/backupVaults/backupInstances ossrg-empdb11

Eseguire un backup su richiesta

Recuperare l'istanza di backup pertinente in cui è necessario attivare un backup usando il Get-AzDataProtectionBackupInstance comando :

$instance = Get-AzDataProtectionBackupInstance -SubscriptionId "xxxx-xxx-xxx" -ResourceGroupName "testBkpVaultRG" -VaultName $TestBkpVault.Name -Name "BackupInstanceName"

È possibile specificare una regola di conservazione durante l'attivazione di un backup. Per visualizzare le regole di conservazione in un criterio, esplorare l'oggetto criterio. Nell'esempio seguente viene visualizzata la regola con il nome Default . Questo articolo usa tale regola di esempio per il backup su richiesta.

$ossPol.PolicyRule | fl


BackupParameter           : Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.Api20210201Preview.AzureBackupParams
BackupParameterObjectType : AzureBackupParams
DataStoreObjectType       : DataStoreInfoBase
DataStoreType             : OperationalStore
Name                      : BackupHourly
ObjectType                : AzureBackupRule
Trigger                   : Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.Api20210201Preview.ScheduleBasedTriggerContext
TriggerObjectType         : ScheduleBasedTriggerContext

IsDefault  : True
Lifecycle  : {Microsoft.Azure.PowerShell.Cmdlets.DataProtection.Models.Api20210201Preview.SourceLifeCycle}
Name       : Default
ObjectType : AzureRetentionRule

Per attivare un backup su richiesta, usare il Backup-AzDataProtectionBackupInstanceAdhoc comando :

$AllInstances = Get-AzDataProtectionBackupInstance -ResourceGroupName "testBkpVaultRG" -VaultName $TestBkpVault.Name
Backup-AzDataProtectionBackupInstanceAdhoc -BackupInstanceName $AllInstances[0].Name -ResourceGroupName "testBkpVaultRG" -VaultName $TestBkpVault.Name -BackupRuleOptionRuleName "Default"

Tenere traccia dei lavori

Tenere traccia di tutti i processi usando il Get-AzDataProtectionJob comando . È possibile elencare tutti i lavori e ottenere i dettagli di un particolare lavoro.

È anche possibile usare Az.ResourceGraph per tracciare tutti i processi in tutti i backup vault. Usare il comando Search-AzDataProtectionJobInAzGraph per recuperare i processi pertinenti negli insiemi di credenziali per il backup:

  $job = Search-AzDataProtectionJobInAzGraph -Subscription $sub -ResourceGroupName "testBkpVaultRG" -Vault $TestBkpVault.Name -DatasourceType AzureDisk -Operation OnDemandBackup

Contenuto correlato

  • Last updated on