Sauvegarder des bases de données PostgreSQL à l’aide d’Azure CLI

2025-05-20

Cet article explique comment sauvegarder des bases de données PostgreSQL dans des machines virtuelles Azure à l’aide d’Azure CLI. Vous pouvez également configurer la sauvegarde à l’aide du portail Azure, d’Azure PowerShell et de l’API REST pour les bases de données PostgreSQL.

En savoir plus sur les scénarios pris en charge et les questions fréquentes sur la sauvegarde d’Azure Database pour PostgreSQL.

Créer un coffre de sauvegarde

Un coffre de sauvegarde est une entité de stockage dans Azure. Il stocke les données de sauvegarde pour les nouvelles charges de travail qu’Azure Backup prend en charge, telles que les serveurs Azure Database pour PostgreSQL, les objets blob dans un compte de stockage et les disques Azure. Les coffres de sauvegarde vous aident à organiser vos données de sauvegarde tout en réduisant la surcharge de gestion. Les coffres Sauvegarde sont basés sur le modèle Azure Resource Manager, qui fournit des fonctionnalités améliorées pour sécuriser les données de sauvegarde.

Avant de créer un coffre Sauvegarde, choisissez la redondance de stockage des données dans le coffre. Ensuite, procédez à la création du coffre de sauvegarde avec cette redondance de stockage et cet emplacement.

Dans cet article, vous allez créer un coffre de sauvegarde avec le nom TestBkpVault, dans la westus région, sous le groupe testBkpVaultRGde ressources . Utilisez la az dataprotection vault create commande pour créer un coffre de sauvegarde. En savoir plus sur la création d’un coffre de sauvegarde.

az dataprotection backup-vault create -g testBkpVaultRG --vault-name TestBkpVault -l westus --type SystemAssigned --storage-settings datastore-type="VaultStore" type="LocallyRedundant"

{
  "eTag": null,
  "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourcegroups/testBkpVaultRG/providers/Microsoft.DataProtection/BackupVaults/TestBkpVault",
  "identity": {
    "principalId": "aaaaaaaa-bbbb-cccc-1111-222222222222",
    "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "type": "SystemAssigned"
  },
  "location": "westus",
  "name": "TestBkpVault",
  "properties": {
    "provisioningState": "Succeeded",
    "storageSettings": [
      {
        "datastoreType": "VaultStore",
        "type": "LocallyRedundant"
      }
    ]
  },
  "resourceGroup": "testBkpVaultRG",
  "systemData": null,
  "tags": null,
  "type": "Microsoft.DataProtection/backupVaults"
}

Créer une stratégie de sauvegarde

Après avoir créé un coffre, vous pouvez créer une stratégie de sauvegarde pour protéger les bases de données PostgreSQL. Vous pouvez également créer une stratégie de sauvegarde pour les bases de données PostgreSQL à l’aide de l’API REST.

Comprendre la stratégie de sauvegarde PostgreSQL

Alors que la sauvegarde sur disque offre plusieurs sauvegardes par jour et que la sauvegarde blob est une sauvegarde continue sans besoin de déclencheur, la sauvegarde PostgreSQL offre une protection des archives. Les données de sauvegarde qui sont envoyées pour la première fois au coffre peuvent être déplacées vers le niveau archive, en fonction d’une règle définie ou d’un cycle de vie.

Dans ce contexte, la hiérarchie suivante peut vous aider à comprendre l’objet de stratégie de sauvegarde pour PostgreSQL :

Règle de stratégie
- Règle de sauvegarde
  - Paramètre de sauvegarde
    - Type de sauvegarde (sauvegarde complète de la base de données dans ce cas)
    - Magasin de données initial (où les sauvegardes atterrissent initialement)
    - Déclencheur (mode de déclenchement de la sauvegarde)
      - Calendrier
      - Critères d’étiquetage par défaut (tag par défaut qui lie toutes les sauvegardes planifiées à la règle de rétention)
- Règle de rétention par défaut (règle appliquée à toutes les sauvegardes, par défaut, sur le magasin de données initial)

L’objet de stratégie définit quels types de sauvegardes sont déclenchés, comment ils sont déclenchés (via une planification), ce qu’ils sont marqués avec, où ils atterrissent (magasin de données) et le cycle de vie de leurs données dans un magasin de données.

L’objet PowerShell par défaut pour PostgreSQL indique de déclencher une sauvegarde complète chaque semaine. Les sauvegardes atteignent le coffre-fort, où elles sont stockées pendant trois mois.

Si vous souhaitez ajouter le niveau archive à la stratégie, vous devez décider quand les données seront déplacées du coffre vers l’archive, de la durée pendant laquelle les données resteront dans l’archive et quelles sauvegardes planifiées doivent être étiquetées comme archivage. Vous devez ajouter une règle de rétention définissant le cycle de vie des données de sauvegarde du datastore de coffre au datastore d'archive. La règle de rétention définit également la durée pendant laquelle les données de sauvegarde restent dans le magasin de données d’archivage. Ensuite, vous devez ajouter une balise qui marque les sauvegardes planifiées comme pouvant être archivées.

L’objet PowerShell qui en résulte est le suivant :

Règle de stratégie
- Règle de sauvegarde
  - Paramètre de sauvegarde
    - Type de sauvegarde (sauvegarde complète de la base de données dans ce cas)
    - Magasin de données initial (où les sauvegardes atterrissent initialement)
    - Déclencheur (mode de déclenchement de la sauvegarde)
      - Calendrier
      - Critères d’étiquetage par défaut (étiquette par défaut qui relie toutes les sauvegardes programmées à la règle de rétention)
      - Nouveaux critères d’étiquetage pour la nouvelle règle de rétention portant le même nom
- Règle de rétention par défaut (règle appliquée à toutes les sauvegardes, par défaut, sur le magasin de données initial)
- Nouvelle règle de rétention
  - Cycle de vie
    - Magasin de données source
    - Période de suppression dans le système de stockage des données source
    - Copier dans l'entrepôt de données cible

Récupérer le modèle de stratégie

Pour comprendre les composants internes d’une stratégie de sauvegarde pour la sauvegarde de base de données PostgreSQL, récupérez le modèle de stratégie à l’aide de la az dataprotection backup-policy get-default-policy-template commande. Cette commande retourne le modèle de stratégie par défaut pour un type de source de données. Utilisez ce modèle de stratégie pour créer une nouvelle stratégie.

az dataprotection backup-policy get-default-policy-template --datasource-type AzureDatabaseForPostgreSQL
{
  "datasourceTypes": [
    "Microsoft.DBforPostgreSQL/servers/databases"
  ],
  "name": "OssPolicy1",
  "objectType": "BackupPolicy",
  "policyRules": [
    {
      "backupParameters": {
        "backupType": "Full",
        "objectType": "AzureBackupParams"
      },
      "dataStore": {
        "dataStoreType": "VaultStore",
        "objectType": "DataStoreInfoBase"
      },
      "name": "BackupWeekly",
      "objectType": "AzureBackupRule",
      "trigger": {
        "objectType": "ScheduleBasedTriggerContext",
        "schedule": {
          "repeatingTimeIntervals": [
            "R/2021-08-15T06:30:00+00:00/P1W"
          ],
          "timeZone": "UTC"
        },
        "taggingCriteria": [
          {
            "isDefault": true,
            "tagInfo": {
              "id": "Default_",
              "tagName": "Default"
            },
            "taggingPriority": 99
          }
        ]
      }
    },
    {
      "isDefault": true,
      "lifecycles": [
        {
          "deleteAfter": {
            "duration": "P3M",
            "objectType": "AbsoluteDeleteOption"
          },
          "sourceDataStore": {
            "dataStoreType": "VaultStore",
            "objectType": "DataStoreInfoBase"
          },
          "targetDataStoreCopySettings": []
        }
      ],
      "name": "Default",
      "objectType": "AzureRetentionRule"
    }
  ]
}

Le modèle de stratégie se compose d’un déclencheur (qui détermine ce qui déclenche la sauvegarde) et d’un cycle de vie (qui décide quand supprimer, copier ou déplacer la sauvegarde). Dans une sauvegarde de base de données PostgreSQL, la valeur par défaut du déclencheur est un déclencheur hebdomadaire planifié (une sauvegarde tous les sept jours). Chaque sauvegarde est conservée pendant trois mois.

Déclencheur planifié

"trigger": {
        "objectType": "ScheduleBasedTriggerContext",
        "schedule": {
          "repeatingTimeIntervals": [
            "R/2021-08-15T06:30:00+00:00/P1W"
          ],
          "timeZone": "UTC"
        }

Cycle de vie par défaut pour la règle de détention

 {
      "isDefault": true,
      "lifecycles": [
        {
          "deleteAfter": {
            "duration": "P3M",
            "objectType": "AbsoluteDeleteOption"
          },
          "sourceDataStore": {
            "dataStoreType": "VaultStore",
            "objectType": "DataStoreInfoBase"
          },
          "targetDataStoreCopySettings": []
        }
      ],
      "name": "Default",
      "objectType": "AzureRetentionRule"
    }

Modification du modèle de stratégie

Dans Azure PowerShell, vous pouvez utiliser des objets comme emplacements intermédiaires pour effectuer toutes les modifications. Dans Azure CLI, vous devez utiliser des fichiers, car il n’existe aucune notion d’objets. Chaque opération de modification doit être redirigée vers un nouveau fichier, où le contenu est lu à partir du fichier d’entrée et redirigé vers le fichier de sortie. Vous pouvez renommer ultérieurement le fichier en fonction des besoins lors de son utilisation dans un script.

Modification de la planification

Le modèle de stratégie par défaut comporte une sauvegarde par semaine. Vous pouvez modifier la planification de la sauvegarde pour qu’elle se produise plusieurs jours par semaine. Pour modifier la planification, utilisez la az dataprotection backup-policy trigger set commande.

L’exemple suivant modifie la sauvegarde hebdomadaire en dimanche, mercredi et vendredi de chaque semaine. Le tableau de dates de planification mentionne les dates et les jours de la semaine pour ces dates sont pris en tant que jours de la semaine. Vous devez également spécifier que ces planifications se répètent chaque semaine. Par conséquent, l’intervalle de planification est 1 et le type d’intervalle est Weekly.

az dataprotection backup-policy trigger create-schedule --interval-type Weekly --interval-count 1 --schedule-days 2021-08-15T22:00:00 2021-08-18T22:00:00 2021-08-20T22:00:00
[
  "R/2021-08-15T22:00:00+00:00/P1W",
  "R/2021-08-18T22:00:00+00:00/P1W",
  "R/2021-08-20T22:00:00+00:00/P1W"
]

az dataprotection backup-policy trigger set --policy .\OSSPolicy.json  --schedule R/2021-08-15T22:00:00+00:00/P1W R/2021-08-18T22:00:00+00:00/P1W R/2021-08-20T22:00:00+00:00/P1W > EditedOSSPolicy.json

Ajout d’une nouvelle règle de rétention

Si vous souhaitez ajouter une protection d’archivage, vous devez modifier le modèle de stratégie.

Le modèle par défaut a un cycle de vie pour le magasin de données initial sous la règle de rétention par défaut. Dans ce scénario, la règle indique de supprimer les données de sauvegarde au bout de trois mois. Vous devez ajouter une nouvelle règle de rétention qui définit quand les données sont déplacées vers le magasin de données d’archivage. Autrement dit, les données de sauvegarde sont d’abord copiées dans le magasin de données d’archive, puis supprimées dans le magasin de données du coffre.

En outre, la règle doit définir la durée pendant laquelle conserver les données dans le magasin de données d’archivage. Pour créer de nouveaux cycles de vie, utilisez la az dataprotection backup-policy retention-rule create-lifecycle commande. Pour associer ces cycles de vie à des règles nouvelles ou existantes, utilisez la az dataprotection backup-policy retention-rule set commande.

L’exemple suivant crée une règle de rétention nommée Monthly. Dans cette règle, la première sauvegarde réussie de chaque mois est conservée dans le coffre pendant six mois, déplacée vers le niveau archive et conservée dans le niveau archive pendant 24 mois.

az dataprotection backup-policy retention-rule create-lifecycle --retention-duration-count 6 --retention-duration-type Months --source-datastore VaultStore --target-datastore ArchiveStore --copy-option CopyOnExpiryOption > VaultToArchiveLifeCycle.JSON

az dataprotection backup-policy retention-rule create-lifecycle --retention-duration-count 24 --retention-duration-type Months -source-datastore ArchiveStore > OnArchiveLifeCycle.JSON

az dataprotection backup-policy retention-rule set --lifecycles .\VaultToArchiveLifeCycle.JSON .\OnArchiveLifeCycle.JSON --name Monthly --policy .\EditedOSSPolicy.JSON > AddedRetentionRulePolicy.JSON

Ajout d’une étiquette et des critères pertinents

Après avoir créé une règle de rétention, vous devez créer une balise correspondante dans la Trigger propriété de la stratégie de sauvegarde. Pour créer de nouveaux critères d’étiquetage, utilisez la az dataprotection backup-policy tag create-absolute-criteria commande. Pour mettre à jour la balise existante ou créer une balise, utilisez la az dataprotection backup-policy tag set commande.

L’exemple suivant crée une balise avec les critères, qui est la première sauvegarde réussie du mois. L’étiquette a le même nom que la règle de conservation correspondante à appliquer.

Dans cet exemple, les critères d’étiquette sont nommés Monthly:

az dataprotection backup-policy tag create-absolute-criteria --absolute-criteria FirstOfMonth > tagCriteria.JSON
az dataprotection backup-policy tag set --criteria .\tagCriteria.JSON --name Monthly --policy .\AddedRetentionRulePolicy.JSON > AddedRetentionRuleAndTag.JSON

Si la planification est de plusieurs sauvegardes par semaine (tous les dimanches, mercredis et jeudis, comme indiqué dans l’exemple précédent) et que vous souhaitez archiver les sauvegardes dimanche et vendredi, vous pouvez modifier les critères d’étiquetage à l’aide de la az dataprotection backup-policy tag create-generic-criteria commande :

az dataprotection backup-policy tag create-generic-criteria --days-of-week Sunday Friday > tagCriteria.JSON
az dataprotection backup-policy tag set --criteria .\tagCriteria.JSON --name Monthly --policy .\AddedRetentionRulePolicy.JSON > AddedRetentionRuleAndTag.JSON

Création d’une stratégie de sauvegarde PostgreSQL

Après avoir modifié le modèle en fonction des exigences, utilisez la az dataprotection backup-policy create commande pour créer une stratégie à l’aide du modèle modifié :

az dataprotection backup-policy create --backup-policy-name FinalOSSPolicy --policy AddedRetentionRuleAndTag.JSON --resource-group testBkpVaultRG --vault-name TestBkpVault

Configurer une sauvegarde

Après avoir créé le coffre et la stratégie, vous devez prendre en compte trois points critiques pour sauvegarder une base de données PostgreSQL dans Azure Database pour PostgreSQL.

Comprendre les entités clés

Base de données PostgreSQL à sauvegarder

Récupérez l’ID Resource Manager de la base de données PostgreSQL à sauvegarder. Cet ID sert d’identificateur de la base de données. L’exemple suivant utilise une base de données nommée empdb11 sous le serveur testposgresqlPostgreSQL, qui est présente dans le groupe ossrg de ressources sous un autre abonnement. L’exemple utilise Bash.

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

Coffre-fort de clés

Le service Sauvegarde Azure ne stocke pas le nom d’utilisateur ni le mot de passe permettant de se connecter à la base de données PostgreSQL. Au lieu de cela, l’administrateur de sauvegarde place les clés dans le coffre de clés. Le service Sauvegarde Azure accède ensuite au coffre de clés, lit les clés et accède à la base de données.

L’exemple suivant utilise Bash. Notez l’identificateur de secret de la clé concernée.

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

Coffre de sauvegarde

Un coffre de sauvegarde doit se connecter au serveur PostgreSQL, puis accéder à la base de données via les clés présentes dans le coffre de clés. Par conséquent, le coffre de sauvegarde nécessite l’accès au serveur PostgreSQL et au coffre de clés. L'accès est accordé à l'identité gérée du coffre-fort de sauvegarde.

Découvrez les autorisations que vous devez accorder à l’identité managée du coffre de sauvegarde sur le serveur PostgreSQL et le coffre de clés qui stocke les clés dans la base de données.

Préparer la requête

Après avoir défini toutes les autorisations appropriées, effectuez la configuration de la sauvegarde en deux étapes :

Préparez la requête à l’aide du coffre, de la stratégie et de la base de données PostgreSQL appropriés dans la commande az dataprotection backup-instance initialize.
Envoyez la demande pour sauvegarder la base de données à l’aide de la az dataprotection backup-instance create commande.

az dataprotection backup-instance initialize --datasource-id $ossId --datasource-type AzureDatabaseForPostgreSQL -l <vault-location> --policy-id <policy_arm_id>  --secret-store-type AzureKeyVault --secret-store-uri $keyURI > OSSBkpInstance.JSON

az dataprotection backup-instance create --resource-group testBkpVaultRG --vault-name TestBkpVault TestBkpvault --backup-instance .\OSSBkpInstance.JSON

Exécuter une sauvegarde à la demande

Vous devez spécifier une règle de rétention pendant que vous déclenchez la sauvegarde. Pour afficher les règles de rétention dans une stratégie, parcourez le fichier JSON de stratégie. Dans l’exemple suivant, il existe deux règles de rétention avec les noms Default et Monthly. Cet article utilise la Monthly règle pour la sauvegarde à la demande.

az dataprotection backup-policy show  -g ossdemorg --vault-name ossdemovault-1 --subscription e3d2d341-4ddb-4c5d-9121-69b7e719485e --name osspol5
{
  "id": "/subscriptions/e3d2d341-4ddb-4c5d-9121-69b7e719485e/resourceGroups/ossdemorg/providers/Microsoft.DataProtection/backupVaults/ossdemovault-1/backupPolicies/osspol5",
  "name": "osspol5",
  "properties": {
    "datasourceTypes": [
      "Microsoft.DBforPostgreSQL/servers/databases"
    ],
    "objectType": "BackupPolicy",
    "policyRules": [
      {
        "backupParameters": {
          "backupType": "Full",
          "objectType": "AzureBackupParams"
        },
        "dataStore": {
          "dataStoreType": "VaultStore",
          "objectType": "DataStoreInfoBase"
        },
        "name": "BackupWeekly",
        "objectType": "AzureBackupRule",
        "trigger": {
          "objectType": "ScheduleBasedTriggerContext",
          "schedule": {
            "repeatingTimeIntervals": [
              "R/2020-04-04T20:00:00+00:00/P1W",
              "R/2020-04-01T20:00:00+00:00/P1W"
            ],
            "timeZone": "UTC"
          },
          "taggingCriteria": [
            {
              "criteria": [
                {
                  "absoluteCriteria": [
                    "FirstOfMonth"
                  ],
                  "daysOfMonth": null,
                  "daysOfTheWeek": null,
                  "monthsOfYear": null,
                  "objectType": "ScheduleBasedBackupCriteria",
                  "scheduleTimes": null,
                  "weeksOfTheMonth": null
                }
              ],
              "isDefault": false,
              "tagInfo": {
                "eTag": null,
                "id": "Monthly_",
                "tagName": "Monthly"
              },
              "taggingPriority": 15
            },
            {
              "criteria": null,
              "isDefault": true,
              "tagInfo": {
                "eTag": null,
                "id": "Default_",
                "tagName": "Default"
              },
              "taggingPriority": 99
            }
          ]
        }
      },
      {
        "isDefault": false,
        "lifecycles": [
          {
            "deleteAfter": {
              "duration": "P10Y",
              "objectType": "AbsoluteDeleteOption"
            },
            "sourceDataStore": {
              "dataStoreType": "VaultStore",
              "objectType": "DataStoreInfoBase"
            },
            "targetDataStoreCopySettings": []
          }
        ],
        "name": "Monthly",
        "objectType": "AzureRetentionRule"
      },
      {
        "isDefault": true,
        "lifecycles": [
          {
            "deleteAfter": {
              "duration": "P1Y",
              "objectType": "AbsoluteDeleteOption"
            },
            "sourceDataStore": {
              "dataStoreType": "VaultStore",
              "objectType": "DataStoreInfoBase"
            },
            "targetDataStoreCopySettings": []
          }
        ],
        "name": "Default",
        "objectType": "AzureRetentionRule"
      }
    ]
  },
  "resourceGroup": "ossdemorg",
  "systemData": null,
  "type": "Microsoft.DataProtection/backupVaults/backupPolicies"
}

Pour déclencher une sauvegarde à la demande, utilisez la az dataprotection backup-instance adhoc-backup commande :

az dataprotection backup-instance adhoc-backup --name "ossrg-empdb11" --rule-name "Monthly" --resource-group testBkpVaultRG --vault-name TestBkpVault

Suivre les travaux

Effectuez le suivi de tous les travaux à l’aide de la az dataprotection job list commande. Vous pouvez répertorier tous les travaux et extraire le détail d’un travail particulier.

Vous pouvez également utiliser Az.ResourceGraph pour suivre tous les travaux dans l’ensemble des coffres de sauvegarde. Utilisez la commande az dataprotection job list-from-resourcegraph pour extraire les travaux pertinents dans les coffres de sauvegarde :

az dataprotection job list-from-resourcegraph --datasource-type AzureDatabaseForPostgreSQL --status Completed

Restaurez des bases de données PostgreSQL à l’aide d’Azure CLI.
Restaurez une base de données PostgreSQL à l’aide du portail Azure, d’Azure PowerShell et de l’API REST.

Partager via