Sauvegarde et restauration de la base

Sommaire
  1. Généralités sur la méthode
  2. Attribution des droits lors de la restauration
  3. Sauvegarde et restauration de schémas ou d'objets contenus dans les schémas

Généralités sur la méthode⚓

ASGARD étant une extension PostgreSQL, elle est gérée comme telle pour les sauvegardes et restaurations. Aucune manipulation spécifique n'est requise. En particulier, il n'y a pas lieu de réinstaller manuellement l'extension, car le fichier de sauvegarde contient déjà :

  • une commande CREATE EXTENSION asgard qui, lors de la restauration, réinstallera automatiquement l'extension ;

  • les données de la table de gestion[1].

ProcédureProcédure classique de sauvegarde/restauration⚓

  1. Sauvegarder la base originale (avec la méthode habituelle)

  2. Vérifier que l'extension ASGARD est disponible sur le serveur de restauration

    Les fichiers d'ASGARD doivent être présents dans le répertoire des extensions du serveur sur lequel sera effectuée la restauration, sans quoi l'extension ne pourra pas être réinstallée et le contenu de la table de gestion serait perdu.

    Il est par ailleurs souhaitable que la version de l'extension ASGARD installée sur la base sauvegardée soit identique à la version considérée comme « de référence » au moment de la restauration.

    Cette « version de référence » est celle qui apparaît dans le fichier asgard.control présent dans le répertoire des extensions du serveur. Il s’agit toujours de la version la plus récente disponible sur le serveur. Pour plus de détails, cf. Activation de l'extension sur une base (encart Précisions sur la version de référence).

    Concrètement, un décalage de version ne sera problématique que si la structure de la table z_asgard_admin.gestion_schema a été modifiée entre les deux versions. Dans ce cas, les informations saisies dans la table de gestion seraient perdues lors de la restauration. Reste que cette situation est très improbable, conserver la structure de gestion_schema étant une priorité lors des développements.

    Nonobstant, par précaution, on recommandera de mettre à jour systématiquement l’extension ASGARD sur toutes les bases où elle est installée dès qu’une nouvelle version est mise à disposition. Cf. Mise à jour de l'extension pour les modalités de mise à jour.

  3. Créer une base vierge sur le serveur de restauration

  4. Restaurer le fichier de sauvegarde dans cette base (avec la méthode habituelle)

    Attention

    La restauration d'une base « asgardisée » ne peut être réalisée que par un super-utilisateur[2], car elle implique implicitement la réinstallation de l'extension, opération que seul un super-utilisateur est habilité à réaliser.

    Il importe de ne pas utiliser l'option --disable-triggers de pg_restore. Il est en effet nécessaire que les déclencheurs d'Asgard soient actifs pendant le processus de restauration pour assurer l'intégrité des données de la table de gestion. À défaut, il sera au moins indispensable d'appliquer immédiatement la fonction asgard_nettoyage_oids à l'issue de la restauration.

    Remarque

    Dans le cas très hypothétique où la structure de certains objets de l’extension aurait été modifiée manuellement par l’administrateur, ils seraient recréés dans leur état d’origine, tel que défini par le script d'installation de l’extension, et les modifications seraient perdues.

  5. Résultat

    Sans qu'aucune autre opération ne soit nécessaire, l'extension ASGARD est active sur la nouvelle base, avec une table de gestion[1] contenant les mêmes informations (éditeurs, lecteurs, nomenclature, etc.) que sur l'ancienne.

    Cette règle connaît une exception : lorsque des extensions qui créent leurs propres schémas sont actives sur la base, lesdits schémas seront toujours automatiquement référencés[3] lors de la restauration de la base, même s'ils ne l'étaient pas auparavant. Comme pour tout référencement de schéma, ceci implique que le propriétaire/producteur du schéma deviendra propriétaire de tous les objets qui lui sont rattachés s'il ne l'était pas déjà. Il reste possible de déréférencer le schéma a posteriori avec asgard_sortie_gestion_schema.

Commentaires
Attention

Avec les versions d'ASGARD strictement antérieures à la v1.4.1, des précautions particulières doivent être prises pour assurer la bonne restauration d'une base sur laquelle, en plus d'ASGARD, sont actives une ou plusieurs extensions qui créent leurs propres schémas, lorsque lesdits schémas sont référencés[3] dans la table de gestion[1] d'ASGARD. En particulier, l'extension PlumePg et son schéma z_plume sont concernés.

À défaut, le contenu de la table de gestion est susceptible d'être perdu lors de la restauration, ce qui équivaut au déréférencement[4] brutal de tous les schémas de la base, qui ne seront dès lors plus considérés par les mécanismes automatisés d'ASGARD. Il reste possible de les référencer de nouveau avec les fonctions asgard_initialisation_gestion_schema ou asgard_initialise_schema, mais certaines informations devront alors être ressaisies manuellement (éditeur[5], lecteur[6], etc.).

Il est possible d'éviter ce problème en appliquant l'une des trois méthodes suivantes :

  • (recommandé) Mettre à jour ASGARD en version 1.4.1 ou supérieur.

  • Ne pas référencer les schémas créés par les extensions dans la table de gestion d'ASGARD, ou du moins les déréférencer manuellement avant la sauvegarde avec la fonction asgard_sortie_gestion_schema.

  • Procéder à une restauration par étape de la base :

    1. Restaurer d'abord la structure seule avec l'option -s / --schema-only de pg_restore.

    2. Appliquer asgard_sortie_gestion_schema à tous les schémas qui auront été créés par des extensions au cours de l'étape précédente, par exemple avec la commande suivante :

      1
      SELECT
      2
          pg_namespace.nspname AS nom_schema,
      3
          pg_extension.extname AS nom_extension,
      4
          z_asgard_admin.asgard_sortie_gestion_schema(pg_namespace.nspname) AS dereferencement
      5
          FROM pg_depend
      6
              INNER JOIN pg_extension ON pg_extension.oid = pg_depend.refobjid
      7
              INNER JOIN pg_namespace ON pg_namespace.oid = pg_depend.objid
      8
          WHERE pg_depend.deptype = 'e'
      9
              AND pg_depend.classid = 'pg_namespace'::regclass
      10
              AND pg_depend.refclassid = 'pg_extension'::regclass
      11
              AND NOT pg_namespace.nspname IN ('z_asgard', 'z_asgard_admin') ;

    3. Restaurer les données avec l'option -a / --data-only de pg_restore.

Plus de précisions dans l'issue #17 du GitHub de l'extension ASGARD.

ComplémentPour en savoir plus sur les outils de sauvegarde et restauration⚓

Pour de plus amples informations sur les processus de sauvegarde et de restauration des bases PostgreSQL, on pourra se reporter :

Attribution des droits lors de la restauration⚓

Quelle que soit la méthode utilisée, les informations saisies dans la table de gestion sont intégralement conservées lors du processus et les droits des producteurs[7], éditeurs[5] et lecteurs[6] seront quoi qu'il arrive ré-appliqués lors de la restauration.

Ainsi :

  • si la table de gestion faisait référence à des rôles qui, pour une raison ou une autre, n'existent pas sur le serveur de destination, ils seront recréés pendant la restauration (en tant que rôles de groupe[8] sans attribut particulier) et recevront les droits prévus pour eux dans la table de gestion ;

  • si certains schémas avaient été exclus de la sauvegarde (commande -N de pg_dump) alors qu'ils étaient référencés dans la table de gestion[3], ces schémas seront recréés – évidemment vides – lors de la restauration. Le propriétaire du schéma sera le producteur identifié dans la table de gestion et, s'il y avait un éditeur ou un lecteur, il aura accès au schéma ;

  • si la sauvegarde avait été configurée de manière à ce que les propriétaires et/ou les droits ne soient pas enregistrés (commandes -O et -x de pg_dump), les droits prévus dans la table de gestion pour les schémas qui y sont référencés n'en seront pas moins appliqués : le producteur sera propriétaire de tous les objets, l'éditeur et le lecteur recevront les privilèges standards prévus par ASGARD pour ces profils.

Si l'administrateur avait personnalisé les droits[9] sur certains objets, cette personnalisation sera reproduite si et seulement si la sauvegarde avait été configurée de manière à enregistrer les droits (ce qui est le paramétrage par défaut lorsqu'on utilise la fonctionnalité de sauvegarde de pgAdmin ou directement pg_dump en ligne de commande). Sinon, la restauration aura pour effet de rétablir les droits standards d'ASGARD sur les schémas référencés.

Attention

La personnalisation des droits est toujours conservée à l'identique, sauf si elle avait consisté à révoquer une partie des privilèges du lecteur ou de l'éditeur. Ceux-ci retrouveront a minima leurs privilèges standards (voire davantage dans le cas d'une personnalisation leur conférant des droits supplémentaires et si les droits avaient été enregistrés lors de la sauvegarde). Les révocations de privilèges du producteur sont par contre préservées (dès lors que l'export avait été configuré pour enregistrer les droits).

Sauvegarde et restauration de schémas ou d'objets contenus dans les schémas⚓

La table de gestion, avec toutes les informations relatives au paramétrage des droits qu'elle contient, n'a pas vocation à faire l'objet de sauvegardes indépendantes, et PostgreSQL ne le permet d'ailleurs pas. Les schémas z_asgard_admin et z_asgard, la table gestion_schema, les fonctions, les vues et les déclencheurs d'ASGARD sont des objets liés à l'extension ASGARD, que PostgreSQL gère comme un tout.

Concrètement, tenter de sauvegarder z_asgard_admin ou n'importe quel objet d'ASGARD avec pg_dump ne produira qu'un fichier vide de toute commande ou donnée.

Ceci ne vaut bien sûr que pour les objets d'ASGARD. Outre les sauvegardes à l'échelle de la base, pgAdmin et les exécutables de PostgreSQL permettent de sauvegarder et restaurer/importer des schémas ou des objets (tables, notamment) et ces possibilités ne sont évidemment pas remises en cause par ASGARD. Pour plus de précisions sur ce point, on se reportera à la partie Import de schémas.