Sauvegarde et restauration de la base⚓

La présence de PlumePg ne requiert aucune adaptation du processus de sauvegarde et restauration. Pour que les données de PlumePg soient préservées lors de la restauration, notamment les modèles de formulaire, il est même absolument essentiel de ne pas chercher à réinstaller manuellement l’extension sur la base de restauration. Tout est automatique.

On veillera seulement à ce que :

  • Les fichiers d’installation de PlumePg soient disponibles sur le serveur de restauration.

  • La version par défaut de PlumePg sur le serveur de restauration soit identique à celle qui est effectivement installée sur la base à sauvegarder. Selon le cas, ceci peut supposer de mettre à jour PlumePg sur le serveur d'origine avant la sauvegarde.

La version « par défaut » apparaît dans le fichier d'installation plume_pg.control et peut également être consultée avec la requête suivante, à exécuter sur n’importe quelle base du serveur de restauration :

1
2
SELECT name, default_version FROM pg_available_extensions WHERE name = 'plume_pg' ;
Pour connaître la version installée sur la base à sauvergarder, on pourra par exemple exécuter la commande suivante sur cette base :
1
2
SELECT name, installed_version FROM pg_available_extensions WHERE name = 'plume_pg' ;
Conseil
Il est fortement recommandé de ne pas utiliser l'option --disable-triggers de pg_restore. Il est en effet nécessaire que les déclencheurs de Plume soient actifs pendant le processus de restauration pour que celui-ci se déroule sans erreur.
Attention
Avec les versions d'Asgard strictement antérieures à la 1.4.1, des précautions doivent être prises pour assurer la bonne restauration d'une base sur laquelle :
  • les extensions Asgard et PlumePg sont activées simultanément ;
  • le schéma z_plume de PlumePg est référencé dans la table de gestion d'Asgard.
À défaut, le contenu de la table de gestion d'Asgard est susceptible d'être perdu au cours de la restauration, ce qui équivaut au déréférencement 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, mais certaines informations devront alors être ressaisies manuellement (éditeur, lecteur, 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 le schéma z_plume dans la table de gestion d'Asgard.
    À noter que ce schéma est automatiquement référencé à l'installation de PlumePg si Asgard était déjà active sur la base. Il est également référencé à chaque restauration de la base, même s'il ne l'était pas initialement.
    Il faudra donc le déréférencer avec la fonction d'Asgard prévue à cet effet, z_asgard_admin.asgard_sortie_gestion_schema :
    1
    2
    SELECT z_asgard_admin.asgard_sortie_gestion_schema('z_plume') ;
  • 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. Exécuter la commande ci-dessous sur la base en cours de restauration.
      1
      2
      SELECT z_asgard_admin.asgard_sortie_gestion_schema('z_plume') ;
    3. Restaurer les données seules avec l'option -a / --data-only de pg_restore.
Plus de précisions dans l'issue #17 du GitHub d'Asgard.
Considérations spécifiques au mécanisme d’enregistrement des dates⚓
En l’état actuel, au contraire des informations relatives aux modèles, les données stockées dans la table z_plume.stamp_timestamp dans le cadre du mécanisme d'enregistrement des dates ne sont pas conservées en cas de sauvegarde et restauration de la base. Il faudra qu’elles aient été préalablement intégrées aux fiches de métadonnées pour ne pas être perdues. Cette intégration s’effectue en principe lors de l’édition des fiches de métadonnées avec le plugin QGIS, sous réserve d’avoir activé la fonctionnalité de calcul des catégories dct:created et dct:modified. Pour les dates de dernière modification, elle peut aussi être réalisée automatiquement côté serveur en activant le déclencheur prévu à cet effet.
Les déclencheurs et déclencheurs sur évènement retrouvent par ailleurs leur état initial inactif après la restauration. Ils devront donc être réactivés manuellement d’autant que de besoin. Il n’est pas nécessaire de chercher à recréer les déclencheurs plume_stamp_data_edit sur les tables, ils sont pour leur part restaurés.