Sauvegarde et restauration de la base
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édure : Procédure classique de sauvegarde/restauration⚓
Sauvegarder la base originale (avec la méthode habituelle)
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.controlpré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_schemaa é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 degestion_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.
Créer une base vierge sur le serveur de restauration
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.
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.
- 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 contenant les mêmes informations (éditeurs, lecteurs, nomenclature, etc.) que sur l'ancienne.
Complément : Pour 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 :
à la partie dédiée de la documentation de PostgreSQL ;
à la partie dédiée de la documentation de pgAdmin.
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[3], éditeurs[4] et lecteurs[5] 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[6] 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[7], 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[8] 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.