Installation de Borg

• Borg Backup
• Borgomatic
• Docker Borgomatic
• Tuto mise en place de Borg

• Se connecter au serveur "bkp-srv" en tant qu'admin : ssh admin@bkp-<region>-sinp
• Passer en root : sudo -i
• Créer l'utilisateur "backups" sans mot de passe (connexion par clé SSH) avec son dossier /home/backups : useradd backups --create-home --home-dir /home/backups/ --shell /bin/bash
• Créer le dossier qui contiendra les infos concernant SSH : mkdir /home/backups/.ssh ; chmod 700 /home/backups/.ssh
• Créer le fichier qui contiendra les clés SSH autorisées : touch /home/backups/.ssh/authorized_keys ; chmod 600 /home/backups/.ssh/authorized_keys
• Attribuer la propriété du dossier et de son contenu à l'utilisateur backups : chown -R backups: /home/backups/.ssh

Afin d'autoriser les machines accédant à l'utilsateur admin sur "bkp-srv" à accéder à l'utilisateur backups, nous allons copier le contenu du fichier /home/admin/.ssh/authorized_keys :

• En tant que root sur "bkp-srv" : cat /home/admin/.ssh/authorized_keys >> /home/backups/.ssh/authorized_keys
• Tester la connexion depuis votre machine locale (aucun mot de passe ne doit être demandé) : ssh backups@bkp-<region>-sinp

Sur l'instance "bkp-srv" hébergeant les dépôts Borg, nous installerons Borg avec Pip afin d’accéder aux dernières versions disponibles rapidement :

• Se connecter au serveur "bkp-srv" en tant qu'admin : ssh admin@bkp-<region>-sinp
• Passer en root : sudo -i
• En tant que root, installer les paquets système nécessaire :
  • Debian 11/12 avec Pyfuse3 : apt install python3 python3-pip python3-virtualenv openssl libssl-dev libacl1-dev libacl1 build-essential pkg-config fuse3 libfuse3-dev
  • Debian 10 avec llfuse: apt install python3 python3-pip python3-virtualenv openssl libssl-dev libacl1-dev libacl1 build-essential pkg-config fuse libfuse-dev
• En tant que backups (ou root), installer l'environnement virtuel : virtualenv --python=python3 borg-env
• Activer l'environnement : source borg-env/bin/activate
• Installer les dépendances : pip install -U pip setuptools wheel
• Installer Borg Backup avec le support pour Fuse, si le container utilise :
  • Debian 11/12 avec pyfuse3 : pip install borgbackup[pyfuse3]
  • Debian 10 avec llfuse : pip install borgbackup[llfuse]
• Sortir de l'environnement virtuel : deactivate
• Notes : il peut être intéressant d'installer borg sur l'utilisateur root afin de pouvoir accéder au dossier accessible uniquement par root sur le dépôt "db-srv". C'est le cas des fichiers de sauvegarde des bases de données.

Pour accéder à Borg sans activer l'environnement virtuel :

• Créer un dossier ~/bin avec : mkdir ~/bin
• Modifier les fichiers :
  • ~/.profile : ajouter le code ci-dessous au début du fichier ~/.profile afin d'autoriser l'accès aux exécutable du dossier ~/bin lors d'un accès par SSH avec shell interactif : vi ~/.profile
  • ~/.bashrc : ajouter le code ci-dessous au début du fichier ~/.bashrc avant la ligne de commentaire # If not running interactively, don't do anything. Sinon, l'accès à la commande borg via ssh avec un shell non interactif (ex. container borgmatic) ne fonctionnera pas !
  • Remplacer le code existant de création du dossier bin de l'utilisateur par celui-ci :

    # Set PATH here to include user's private bin for SSH login
    # It's necessary for using Borg !
    if [[ -d "${HOME}bin" && ":$PATH:" != *":${HOME}bin:"* ]] ; then
        PATH="${HOME}bin:${PATH}"
    fi

  • Pour root, ajouter le code ci-dessous :

    # Set PATH here to include user's private bin for SSH login
    # It's necessary for using Borg !
    if [[ -d "/root/bin" && ":$PATH:" != *":/root/bin:"* ]] ; then
        PATH="/root/bin:${PATH}"
    fi

• Vérifier que l'environnement virtuelle est bien désactivé : deactivate
• Recharger l'environnement : source ~/.bashrc
• Ajouter le lien symbolique vers l'executable de Borg : ln -s ~/borg-env/bin/borg ~/bin/borg
• Tester avec la version de Borg : borg --version

• En tant que backups, activer l'environnement : source borg-env/bin/activate
• Pour mettre à jour Borg :
  • Debian 11 avec pyfuse3 : pip install -U borgbackup[pyfuse3]
  • Debian 10 avec llfuse : pip install -U borgbackup[llfuse]

Le dépôt Borg étant distant (hébergé sur l'instance "bkp-srv"), il est nécessaire de créer un clé SSH pour l'utilisateur admin (qui héberge les containers Docker). La clé publique générée sera ensuite copier ans le fichier ~/.ssh/authorized_keys de l'utilisateur backups de l'instance "bkp-srv" afin d'autoriser l'accès au dépôt depuis l'instance à sauvegarder.

• Se connecter à l'instance concernée : ssh admin@<instance>-<region>-sinp
• Générer une clé SSH : ssh-keygen
  • Accepter l'emplacement de stockage de la clef par défaut
  • Laisser une phrase de passe vide pour faciliter l'automatisation des sauvegardes
• Copier la clé publique sur le serveur "bkp-srv" dans le fichier authorized_keys de l'utilisateur backups afin de permettre une connexion SSH sans demande de mot de passe . L'utilisateur backups n'ayant pas de mot de passe, il faut passer par l'utilisateur geonat :
  • Copier de la clé publique : scp -P <port-ssh-bkp-srv> ~/.ssh/id_rsa.pub geonat@bkp-<region>-sinp:~/.ssh/id_rsa.<instance>-srv.pub
  • Se connecter au serveur "bkp-srv" avec l'utilisateur admin : ssh admin@bkp-<region>-sinp
  • Passer en root : sudo -i
  • Ajouter la clé publique de l'instance à sauvegarder au fichier /home/backups/.ssh/authorized_keys de l'utilisateur backups : cat /home/geonat/.ssh/id_rsa.<instance>-srv.pub >> /home/backups/.ssh/authorized_keys
  • Tester la connexion SSH depuis un shell de l'utilisateur admin de l'instance à sauvegarder, aucun mot de passe ne doit être demandé : ssh -p <port-ssh-bkp-srv> backups@bkp-<region>-sinp
  • Si la tentative de connexion s'est déroulé sans demande de mot de passe et avec succès, supprimer le fichier de la clé public de l'instance : rm -f /home/geonat/.ssh/id_rsa.<instance>-srv.pub
• Sur l'instance à sauvegarder et pour l'utilisateur admin, créer un fichier config qui contiendra un paramètre maintenant la connexion SSH : touch ~/.ssh/config; chmod 644 ~/.ssh/config ; vi ~/.ssh/config
  • Y ajouter le contenu suivant :

    Host *
        ServerAliveInterval 240

• Tester à nouveau la connexion SSH depuis un shell de l'utilisateur admin de l'instance à sauvegarder, aucun mot de passe ne doit être demandé : ssh -p <port-ssh-bkp-srv> backups@bkp-<region>-sinp
• Créer le dossier qui contiendra les informations SSH utilisées par le docker Borgmatic : mkdir -p ~/docker/borgmatic/data/.ssh
• Copier le dossier ~/.ssh de l'utilisateur admin dans le dossier data de Borgmatic : sudo cp -r ~/.ssh/ ~/docker/borgmatic/data/
  • l'associer à l'utilisateur root car c'est l'utilisateur root qui l'utilisera dans le container : sudo chown root: -R ~/docker/borgmatic/data/.ssh
  • ATTENTION : Le docker Borgmatic se connectera à l'instance "bkp-srv" avec les infos contenues dans le dossier ~/docker/borgmatic/data/.ssh.

• Au préalable, mettre à jour les fichiers Docker pour l'instance concernée.
• Réaliser l'installation du container Docker Borgmatic

• Afin de pouvoir accéder au port 5432 sur l'IP "gateaway" du container Docker, il faut modifier le fichier : vi postgresql.conf
  • Ajouter l'IP 172.18.0.1 au paramètre listen_addresses
• Il faut ensuite configurer l'accès aux bases à sauvegarder depuis l'IP du container Borgmatic. Le container créé a une IP privée au format 192.168.xxx.xxx, nous ajoutons donc avec /16 un ensemble d'IP privé qui devrait convenir dans la plupart des cas. Si nécessaire vérifier l'IP obtenu par votre container à l'aide de Portainer par exemple. Pour éditer la config de Postgresql : vi pg_hba.conf
  • Ajouter :

    host    geonature2db    geonatadmin     172.18.5.1/16           scram-sha-256
    host    gnatlas         geonatadmin     172.18.5.1/16           scram-sha-256
    # Voir s'il n'est pas possible d'utiliser l'utilisateur geonatadmin à la place de postgres...
    host    gnatlas         postgres        172.18.5.1/16           trust
    host    geonature2db    postgres        172.18.5.1/16           trust

• Il faut aussi s'assurer que le service Systemd de Postgresql démarre toujours après celui de Docker si l'on veut que Postgresql écoute sur l'IP 172.18.5.1. Pour cela surcharger le service de Postgresq: systemctl edit postgresql@.service
  • Ajouter le contenu suivant :

    [Unit]
    After=docker.service

  • Vérifier la présence du fichier : vi /etc/systemd/system/postgresql@.service.d/override.conf

• Générer en local un UUID pour la passphrase de la clé de cryptage des dépôts local et distant de l'instance concernée : uuid
  • Stocker cette passphrase dans Keepass
• Sur l'instance bkp-srv, en tant qu'utilisateur backups, créer le dossier qui contiendra les dépôts : sudo -i ; su - backups ; mkdir ~/<instance>-srv
• Se connecter à l'instance concernée : ssh admin@<instance>-<region>-sinp
  • Modifier le fichier ~/docker/borgmatic/.env de l'instance en ajoutant sa passphrase comme valeur du paramètre BORG_PASSPHRASE : vi ~/docker/borgmatic/.env
• Accéder au container borgmatic pour initialiser le dépôt de l'instance : docker exec -it borgmatic /bin/bash
• Établissez une première connexion au serveur du dépôt distant via SSH pour enregistrer le serveur distant : ssh -p <port-ssh-bkp-srv> backups@<bkp-srv-private-ip>
• À l'aide de Borgmatic, initialiser les dépôts de l'instance (présent dans le fichier de config de Borgmatic). Borgmatic se charge d’exécuter les commandes Borg : borgmatic init --encryption repokey-blake2
  • Si besoin, vous pouvez réinitialiser les dépôts en suivant la procédure "Réinitialiser un dépôt" décrite ci-dessous.
• Pour voir les infos concernant un dépôt :
  • Dépôt de "db-srv" : borg info ssh://backups@10.0.1.30:<ssh-port-bkp-srv>/home/backups/db-srv/
  • Dépôt de "web-srv" : borg info ssh://backups@10.0.1.30:<ssh-port-bkp-srv>/home/backups/web-srv/
  • Le dépôt local à chaque instance : borg info /mnt/borg-repository
• Export les clés des dépôts et les stocker dans Keepass :
  • Instance "db-srv" :
    • Dépôt distant : borg key export ssh://backups@10.0.1.30:<ssh-posrt-bkp-srv>/home/backups/db-srv/ /root/.config/borg/db-srv-dist.repo-conf-file.txt ; cat /root/.config/borg/db-srv-dist.repo-conf-file.txt
    • Dépôt local : borg key export /mnt/borg-repository /root/.config/borg/db-srv-local.repo-conf-file.txt ; cat /root/.config/borg/db-srv-local.repo-conf-file.txt
  • Instance "web-srv" :
    • Dépôt distant : borg key export ssh://backups@10.0.1.30:<ssh-posrt-bkp-srv>/home/backups/web-srv/ /root/.config/borg/web-srv-dist.repo-conf-file.txt ; cat /root/.config/borg/web-srv-dist.repo-conf-file.txt
    • Dépôt local : borg key export /mnt/borg-repository /root/.config/borg/web-srv-local.repo-conf-file.txt ; cat /root/.config/borg/web-srv-local.repo-conf-file.txt
• Si l'instance bkp-srv comprend un espace disque supplémentaire monté sur /data, il peut être intéressant de déplacer via un lien symbolique les dépôts Borg créés :
  • Créer le dossier qui contiendra les dépôts : mkdir /data/borg-repos
  • Donner les droits à l'utilisateur backups avec : chown backups: /data/borg-repos
  • Déplacer les dépôts : mv /home/backups/*-srv /data/borg-repos/
  • En tant qu'utilisateur backups : ln -s /data/borg-repos/web-srv /home/backups/web-srv ; ln -s /data/borg-repos/db-srv /home/backups/db-srv
  • Tester l'accès distant depuis un container borgmatic : borg info ssh://backups@10.0.1.30:<ssh-posrt-bkp-srv>/home/backups/web-srv/
• Tester une sauvegarde manuellement pour vérifier que tout fonctionne : borgmatic --verbosity 2 --stats --files

S'il s'avérait nécessaire de réinitialiser un dépôt, la démarche à suivre est la suivante :

• Vérifier les archives actuellement présentes dans les dépôts : borgmatic list
• Supprimer un dépôt : borgmatic borg delete <repo>
  • Ex. : borgmatic borg delete /mnt/borg-repository/
  • ATTENTION : normalement la commande doit demander confirmation. Si cela ne fonctionne pas essayer la commande sans préciser le dépôt : borgmatic borg delete. La commande devrait demander confirmation de la suppression de chaque dépôt.
• Initialiser à nouveau les dépôt : borgmatic init --encryption repokey-blake2
• Vérifier à nouveau les dépôt : borgmatic list
• Récupérer et stocker dans Keepass les nouvelles clés des dépôts (voir la section "Initialisation des dépôts").

Accéder au container borgmatic pour vérifier et tester son contenu : docker exec -it borgmatic /bin/bash

• À l'email adminsys : echo "THIS IS A TEST EMAIL sended to adminsys at $(date "+%F %H:%M")" | mail -s "[${HOSTNAME}] Test email" adminsys@<domaine-sinp>
• À un utilisateur système root : echo "THIS IS A TEST EMAIL sended to root at $(date "+%F %H:%M")" | mail -s "[${HOSTNAME}] Test email" root

• Envoyer un message : telegram-send "Test at `date`"

• Tester les fichiers de configuration de Borgmatic avec : borgmatic config validate (anciennement validate-borgmatic-config )
• ATTENTION : il est maintenant nécessaire d'initialiser les dépôts avant de lancer la commande de test ci-dessous. Voir la section "Initialisation des dépôts".
• Tester une sauvegarde manuellement pour vérifier que tout fonctionne : borgmatic --verbosity 2 --stats --files

• Éditer le fichier /etc/cron.d/borgmatic : vi /etc/cron.d/borgmatic
• Vérifier l'heure de lancement par défaut. Chaque instance devrait avoir une heure différente de sauvegarde. Il vaut mieux éviter de sauvegarder sur les dépôts distants hébergés sur le serveur bkp-srv au même moment.
• Modifier l'heure de lancement par défaut, pour que la sauvegarde démarre seulement quelques minutes plus tard
• ATTENTION : NE PAS Enregistrer les changement avec Crontab. Crontab et les fichiers présent dans le dossier cron.d sont gérés indépendamment. Si vous rajouter le fichier présent dans /ect/cron.d/ à Crontab 2 processus distincts seront lancés. Du coup, Borg affichera des erreurs liées au fichier lock des dépôts.
• Si vous avez correctement configurer l'envoie de message via Telegram, vous devriez recevoir des messages indiquant le démarrage de la sauvegarde à l'heure que vous avez indiqué. Sinon, vous devriez pouvoir voir les logs sur l'interface de Portainer.

• Contexte : tester manuellement le dump lancé par Borgmatic dans le container (si Postgresql est installé sur votre instance).
• Lancer le dump. Ex. :

  PGPASSWORD=<password-geonatadmin> pg_dump --verbose --no-password --clean --if-exists --host 172.18.5.1 --port 5432 --username geonatadmin --format custom geonature2db > /root/geonature2db

• ATTENTION : dans les logs du container, le dump est lancer avec la variable d'env PGPASSWORD qui est non visible !
• Pour réaliser le dump de la base, il faut un utilisateur avec des droits de super utilisateurs, sinon il y a des risques que le dump échoue car l'utilisateur n'aura pas les droits suffisant sur certaines tables ou autres éléments de la base.

Configurer Telegram pour l'utiliser avec Ntfy ou le script telegram-send et envoyer des alertes à l'aide de Borgmatic. Ntfy nécessite d'autoriser manuellement un bot après chaque build/lancement d'un container. Ce n'est pas très pratique. Il vaut mieux utiliser le script telegram-send à la place.

• Installer Telegram sur votre Smartphone et/ou machine locale
• Créer un nouveau Bot d'alerte en envoyant un message au contact BotFather : /newbot
  • Indiquer son nom : <region> SINP Alert Bot
  • Indiquer comment l'appeler : <region>SinpAlertBot
  • Une fois créé, accéder à la liste de vos bot : /mybots
    • Choisir le bot <region>SinpAlertBot
    • Cliquer sur "API Token" pour en créer un nouveau, le copier dans le presse-papier et l'enregistrer sur Keepass.

• Le script telegram-send peut être utilisé pour envoyer des messages directement à un utilisateur ou à un canal (=group)
• Si vous souhaitez créer un "Canal" pour que le bot y envoie les messages :
  • Dans l'interface de Telegram, via le menu, choisir "Nouveau canal"
    • Indiquer le nom du canal : "<REGION> SINP ALERT"
    • Indiquer la description : "Message d'infos et d'alertes du SINP <REGION>."
    • Cliquer sur "Créer"
    • Choisir un canal de type : privé
  • Ajouter le bot <region>SinpAlertBot au canal
    • Le promouvoir en tant qu'admin et lui donner seulement les droits de publier des messages
• Pour récupérer l'ID du canal (=group) et ou simplement l'ID d'un utilisateur, transférer un message envoyé sur le canal ou à l'utilisateur au bot getidsbot.
  • Il affiche les infos concernant le message dont les id qui vous intéresse : le votre ou celui du canal.
    • Afin que tout le monde reçoive bien les notification, utiliser l'ID du Canal.
  • Créer des entrées dans Keepass pour ces infos et renseigner les entrées TELEGRAM_BOT_TOKEN et TELEGRAM_GROUP_ID du fichier .env
• Redémarrer le container pour prendre en compte les changements du .env : docker-compose down ; docker-compose up -d
• Tester l'envoie de message :
  • Se connecter au container borgmatic : docker exec -it borgmatic /bin/bash
  • Envoyer un message : telegram-send "Test at `date`"

• Sur l'instance de serveur que vous souhaiter sauvegarder, se connecter au container borgmatic : docker exec -it borgmatic /bin/bash
  • ATTENTION : cette manipulation est à refaire à chaque nouvelle construction du container !
  • Lancer la commande : ntfy -b telegram send "Telegram configured for ntfy"
    • Coller le token précédemment copier lors de la création du bot
      • Copier le mot de passe qui s'affiche
    • Sur Telegram, ajouter votre bot en contact et le démarrer avec : /start
      • Coller le mot de passe précédemment copié généré par Ntfy
      • Un message de succès devrait s'afficher : Telegram configured for ntfy
  • Tester l'envoie de message sur votre bot : ntfy -b telegram -t Borgmatic send "Borgmatic: test at `date` on ${HOSTNAME} !"
    • Si tout fonctionne correctement, un message devrait être reçu sur votre Bot dans l'interface de Telegram.

• Se connecter à l'instance concernée : ssh admin@<instance>-<region>-sinp
• Se placer dans le dossier ~/docker/borgomatic avec : cd ~/docker/borgomatic
• Arrêter le container de sauvegarde : docker compose down
• Sur l'hôte, créer un dossier temporaire qui contiendra les fichiers ou dossier à restaurer : sudo rm -fR /tmp/restore ; mkdir /tmp/restore
• Lancer un shell interactif avec le dossier précédemment créé lié à l'hôte : docker compose -f docker-compose.yml -f docker-compose.restore.yml run -v /tmp/restore:/tmp/restore borgmatic
• Vous pouvez alors utiliser les commandes borgmatic ou Borg

• Se connecter à l'instance "bkp-srv" en tant que root
• Liste les sauvegardes de l'instance :
  • db-srv : borg list /home/backups/db-srv
  • web-srv : borg list /home/backups/web-srv
• Créer un dossier :
  • pour le point de montage du dépôt Borg : mkdir /tmp/repo
  • pour le dossier qui contiendra les fichiers à restaurer : mkdir /tmp/restore
• Utiliser Fuse pour monter la sauvegarde sur le dossier du point de montage /tmp/repo: borg mount <repo> /tmp/repo
  • Ex. avec le dépôt local : borg mount /home/backups/db-srv /tmp/repo
  • Le dossier /tmp/repo contient les dossiers des différentes sauvegardes. Ex. de dossier sauvegardé le 17 mai 2021 à 13h57 : web-srv-2021-05-17T13:57:02
• Copier les fichiers à restaurer sur l'hôte en les copiant depuis le point de montage vers le dossier lié l'hôte :
  • Ex. pour web-srv : cp -r "/tmp/repo/web-srv-2021-05-17T13:57:02/mnt/source/etc/cron.d/" /tmp/restore/$(date +'%Y-%m-%d')_gnatlas.custom
  • Ex. pour db-srv : cp -r /tmp/repo/db-srv-2022-04-08T01\:07\:55/root/.borgmatic/postgresql_databases/172.18.5.1/geonature2db /tmp/restore/$(date +'%Y-%m-%d')_geonature2db.custom
  • Vérifier las présence des fichiers à restaurer : ls -al /tmp/restore
• Donner les droits d'accès à l'utilisateur admin : chmod 644 /tmp/restore/*.custom
• Démonter le point de montage et quitter le shell interactif : borg umount /tmp/repo
• Récupérer sur votre machine locale l'archive de base de données : scp admin@bkp-<region>-sinp:/tmp/restore/*.custom ./
  • Voir la restauration en local d'une base serveur

• Se placer dans le dossier partagé avec l'hôte car la commande borgmatic extract extrait par défaut une archive ou un chemin particulier dans le dossier courant : cd /tmp/restore
  • Toutefois, il est possible d'utiliser l'option --destination pour préciser l'emplacement de destination.
• Lister les archives (=sauvegardes) disponibles : borgmatic list
  • ATTENTION : la commande ci-dessus listes les archives de tous les dépôts. Récupérer bien le nom de l'archive correspondant au dépôt que vous indiquerez dans la commande d'extraction.
• Extraire l'archive "<archive-name>" du dépôt <repo> dans le dossier partagé avec l'hôte : borgmatic extract --repository <repo> --archive "<archive-name>" --destination /tmp/restore
  • Ex. : borgmatic extract --repository /mnt/borg-repository --archive "web-srv-2021-05-17T13:57:02" --destination /tmp/restore
• Pour extraire seulement un dossier de l'archive utiliser l'option --path avec le chemin du dossier sans slash au début. Ex. : borgmatic extract --repository /mnt/borg-repository --archive "web-srv-2021-05-17T13:57:02" --path "mnt/source/etc" --destination /tmp/restore
• Note concernant la localisation des éléments sauvegardés dans le dossier d'extraction /tmp/restore/ (si le dossier d'extraction est /tmp/restore/) :
  • les fichier ou dossiers systèmes sauvegardés se trouvent dans /tmp/restore/mnt/…
  • les sauvegardes des bases de données se trouvent dans /tmp/restore/root/.borgmatic/postgresql_databases/172.18.0.1/..
• Quitter le container : exit

• Sur l'hôte, écraser les fichiers à restaurer par ceux provenant de la sauvegarde : sudo cp -r /tmp/restore/cron.d/ /etc/
  • Assurez vous que les dossiers et fichiers sont restaurés avec les bons droits d'accès et propriétaire
• Une fois les fichiers/dossiers restaurés vous pouvez supprimer le dossier de restauration et son contenu : rm -fR /tmp/restore
• NOTE : si nécessaire, il est possible de modifier le fichier docker-compose.restore.yml pour monter directement le volume source en écriture ${VOLUME_SOURCE}:/mnt/source afin de remplacer les fichiers de l'hôte directement depuis le shell interactif.

• Lister les archives disponibles : borgmatic list
• Restaurer une base de données directement. ATTENTION : Pour que cela fonctionne, il est nécessaire d'avoir utiliser une super utilisateur dans la config Borgmatic du dump des bases :

   borgmatic restore --repository <repo> --archive <archive> --database <db-name> 

  • Ex. :

     borgmatic restore --repository /mnt/borg-repository/ --archive "db-srv-2021-05-17T01:00:02" --database geonature2db 

  • Si la commande échoue, récupérer dans la console la ligne de commande qui s'affiche, supprimer l'option --no-password et lancer la commande manuellement. Des erreurs plus détaillées s'afficheront.
• Quitter le container : exit

• Sur l'hôte, copier le fichier : sudo cp /tmp/restore/root/.borgmatic/postgresql_databases/172.18.0.1/geonature2db "/tmp/$(date +'%Y-%m-%d')_geonature2db.custom"
• Changer les droits : sudo chown admin: "/tmp/$(date +'%Y-%m-%d')_geonature2db.custom"
• Depuis votre machine locale récupérer l'archive : scp admin@db-<region>-sinp:/tmp/$(date +'%Y-%m-%d')_geonature2db.custom ./

• Penser à relancer le service Borgmatic : docker compose up -d
• Au cas ou Borg échoue à créer/acquérir un verrou : borg break-lock <repo>

• Commencer par extraire une archive dans le dossier /tmp/restore comme indiqué ci-dessus.
  • Ex. :

     borgmatic extract --repository ssh://backups@10.0.1.30:<port-ssh-bkp-srv>/home/backups/db-srv/ --archive "db-srv-2021-05-19T16:09:01" --destination /tmp/restore 

• Supprimer les connexions à la base existante :

   psql -U postgres -h 172.18.0.1 -d gnatlas -c "SELECT pg_terminate_backend(pg_stat_activity.pid) FROM pg_stat_activity WHERE pg_stat_activity.datname = 'geonature2db' ; " 

• Supprimer la base :

   psql -U postgres -h 172.18.0.1 -d gnatlas -c "DROP DATABASE geonature2db;" 

• Recréer une base vide :

   psql -U postgres -h 172.18.0.1 -d gnatlas -c "CREATE DATABASE geonature2db;" 

• Restaurer la base :

   pg_restore --if-exists --exit-on-error --clean --dbname geonature2db --host 172.18.0.1 --port 5432 --username postgres /tmp/restore/root/.borgmatic/postgresql_databases/172.18.0.1/geonature2db 

Si nécessaire, il est aussi possible de manipuler les éléments à restaurer :

• Créer la liste des éléments à restaurer :

   pg_restore --list /tmp/restore/root/.borgmatic/postgresql_databases/172.18.0.1/geonature2db > gn2.list 

  • Éditer le fichier : vi gn2.list
  • Vous pouvez par exemple commenter les lignes mentionnant EXTENSION puis enregistrer et quitter.
• Restaurer la base avec cette liste :

   pg_restore --if-exists --exit-on-error --clean --dbname geonature2db --host 172.18.0.1 --port 5432 --username postgres --use-list gn2.list /tmp/restore/root/.borgmatic/postgresql_databases/172.18.0.1/geonature2db 

En fonction du format de sauvegarde de la base et de l'utilisateur qui l'effectue, la restauration de la base de données ne pourra pas se faire avec la commande borgmatic restore. La base gnatlas contient des vues matérialisées qui posent problèmes car elles sont basées sur des tables "étrangères" (FDW). Or, les informations du Foreign Data Wrapper ne sont pas correctement restaurées (utilisateur, mot de passe) par pg_restore quand la sauvegarde est au format "directory". Avec la version 13+ de Postgresql ce comportement devrait être amélioré. Du coup, la restauration par borgmatic ne fonctionne pas et celle par pg_restore échoue si l'on ne supprime pas les requêtes de rafraîchissement des VM car les tables FDW ne contiennent pas de données et le rafraîchissement des vues échoue.

• Suivre les étapes précédentes visant à extraire une archive dans le dossier /tmp/restore à l'aide de Borgmatic.
• Le dossier de la sauvegarde de la base gnatlas à fournir à pg_restore se trouvera dans : /tmp/restore/root/.borgmatic/postgresql_databases/172.18.0.1/gnatlas
• Si le format "plain" a été utilisé dans le fichier de config de Borgmatic :
  • Il est simplement nécessaire d'utiliser Psql avec l'utilisateur postgres :

     psql -U postgres -h 172.18.0.1 -p 5432 -d gnatlas -f "/tmp/restore/root/.borgmatic/postgresql_databases/172.18.0.1/gnatlas" 

• Si le format "custom" ou "directory" (qui fonctionne pour gnatlas) a été utilisé dans le fichier de config de Borgmatic, nous pouvons utiliser pg_restore :
  • Créer un fichier qui contient la liste des requêtes a exécuter par pg_restore. Nous supprimerons de la liste le rafraichissement des vues :

     pg_restore --list /tmp/restore/root/.borgmatic/postgresql_databases/172.18.0.1/gnatlas | grep -v "MATERIALIZED VIEW DATA" > without_refresh.list 

  • Lancer la restauration de la base en executant seulement les requêtes listés dans le fichier without_refresh.list :

     pg_restore --if-exists --exit-on-error --clean --dbname gnatlas --host 172.18.0.1 --port 5432 --username postgres --use-list without_refresh.list /tmp/restore/root/.borgmatic/postgresql_databases/172.18.0.1/gnatlas 

  • Après avoir restaurer la base, il est nécessaire de reconfigurer le mapping utilisateur du FDW puis de peupler les vues matérialisées avec les données :
    • Sur l'instance "db-srv", lancer les requêtes suivantes :
      • Ajouter l'utilisateur distant au mapping de l'utilisateur "geonatadmin" utilisant la base "gnatlas" :

        sudo -u postgres -s psql -d gnatlas -c "ALTER USER MAPPING FOR geonatadmin SERVER geonaturedbserver OPTIONS (ADD user 'geonatadmin');" 

      • Ajouter le mot de passe de l'utilisateur distant :

        sudo -u postgres -s psql -d gnatlas -c "ALTER USER MAPPING FOR geonatadmin SERVER geonaturedbserver OPTIONS (ADD password '<pwd>');" 

      • Lancer ensuite le rafraichissement des vues :

         psql -h localhost -U geonatadmin -d gnatlas -f /home/geonat/data/atlas/data/sql/02_refresh_mv_data.sql 

Si besoin, pour voir ce qui existe dans la base concernant FDW:

• Se connecter à Postgresql en tant que postgres :

   sudo -u postgres -s psql -d gnatlas 

• Lister les serveurs FDW :

  SELECT * FROM pg_foreign_server; 

• Lister le USER MAPPING :

  SELECT um.*,rolname FROM pg_user_mapping um JOIN pg_roles r ON r.oid = umuser JOIN pg_foreign_server fs ON fs.oid = umserver; 

• Sortir : exit

• Supprimer le cache :

   borg delete --cache-only <repo> 

• Au cas ou Borg échoue à créer/acquérir un verrou :

   borg break-lock <repo>