En résumé
Une sauvegarde complète tient en deux éléments : le dossier de données et la clé secrète. Sans la seconde, la première remonte une instance dont les mots de passe de bases et les jetons git sont illisibles. Si vous utilisez PostgreSQL, sa base s’ajoute à la liste.
Ce qu’il faut sauvegarder
Le dossier de données
Tout ce que vos utilisateurs créent : la base applicative, les fichiers, les dossiers de projets, les copies de travail git. Les images Docker ne contiennent aucune donnée.
La clé secrète
Elle ne vit pas dans le dossier de données : elle est passée en variable d’environnement. Elle doit donc être sauvegardée séparément, dans votre coffre à secrets.
La base PostgreSQL, si vous en utilisez une
Quand la base applicative est déportée, elle n’est plus dans le dossier de données : sauvegardez-la avec vos outils habituels, et de façon cohérente avec le dossier.
Une sauvegarde sans la clé secrète est une sauvegarde incomplète
L’instance remontera et vos utilisateurs se reconnecteront — leurs mots de passe de compte ne dépendent pas de cette clé. Mais chaque mot de passe de base de données, chaque jeton git et chaque clé d’API sera illisible, sans erreur visible, et devra être ressaisi à la main. Voir Configuration.
Ce que vous pouvez exclure
Le sous-dossier de cache — les paquets R et Python partagés — est reconstructible. L’exclure allège considérablement la sauvegarde ; au pire, la première construction d’environnement après restauration sera plus longue. Les envois en cours peuvent également être ignorés.
Sauvegarder proprement
La difficulté n’est pas de copier, c’est de copier un état cohérent : une copie prise pendant qu’une écriture est en cours peut contenir une base à demi écrite.
Arrêtez l’instance, ou prenez un instantané
Le plus sûr est d’arrêter les conteneurs le temps de la copie. À défaut, un instantané de système de fichiers ou de volume donne un point cohérent sans interruption.
Copiez le dossier
Avec vos outils habituels, en préservant les droits. C’est là que le choix d’un dossier monté plutôt que d’un volume Docker nommé paie : le dossier se sauvegarde comme n’importe quel autre.
Notez la version
Conservez à côté de la sauvegarde le numéro de version des images utilisées. Une sauvegarde ne se restaure pas sur une version plus ancienne — voir ci-dessous.
docker compose -f docker-compose.hub.yml down
tar czf linkr-$(date +%F).tar.gz -C /srv linkr
docker compose -f docker-compose.hub.yml up -dRestaurer
Remettez le dossier en place, fournissez la même clé secrète, et démarrez avec une version au moins égale à celle de la sauvegarde. Les migrations nécessaires s’appliquent toutes seules au démarrage.
On ne restaure pas vers une version plus ancienne
Le schéma de la base avance avec les mises à jour, et ces migrations ne se rejouent pas à l’envers. Une sauvegarde prise en version récente ne remonte pas sur une version antérieure : c’est pourquoi il faut noter la version au moment de la sauvegarde.
Vérifiez une restauration au moins une fois
Une sauvegarde qui n’a jamais été restaurée est une hypothèse, pas une garantie. Remontez-la une fois sur une machine de test : connexion, ouverture d’un projet, affichage d’un tableau de bord, et surtout connexion à une base de données — c’est ce dernier point qui révèle une clé secrète absente.
Sauvegarder autrement : git
Le dossier de données protège l’instance. Le versioning git protège le travail, et les deux sont complémentaires.
Une entité liée à un dépôt distant a, par construction, une copie hors de votre serveur : définitions de cohortes, scripts, tableaux de bord. Si l’instance disparaît, ce travail se récupère en clonant les dépôts, même si la sauvegarde manque.
Mais git ne sauvegarde pas les données
Les fichiers de données sont exclus du versioning, sauf marquage explicite. Un dépôt git n’est donc pas une sauvegarde de vos jeux de données — voir Versioning git.
Les comptes, à part
L’onglet Paramètres › Sauvegarde & sync exporte et réimporte les organisations, utilisateurs et rôles, en archive ou vers un dépôt git. C’est utile pour transporter une configuration d’une instance à une autre, ou pour garder trace de l’évolution des rôles.
Les mots de passe ne sont jamais exportés
Un utilisateur importé sans mot de passe arrive désactivé et devra en recevoir un avant de pouvoir se connecter. Cet export ne remplace donc pas une sauvegarde : il transporte une configuration, pas des comptes utilisables en l’état.
Ce que la sauvegarde ne couvre pas
- Les bases de données externes. Une base PostgreSQL ou Oracle interrogée par Linkr reste sauvegardée par son propre exploitant : Linkr n’en détient que l’adresse.
- Les fichiers désignés par leur chemin. Un entrepôt posé sur le serveur et désigné sans copie n’est pas dans le dossier de données — il relève de la sauvegarde du serveur. Voir Fichiers sur le serveur.
- Une installation en mode navigateur. Les données vivent dans le navigateur de chaque personne, hors de portée d’un administrateur. Seul l’export manuel d’un projet les met à l’abri.
Pour aller plus loin
- Configuration — le dossier de données, dossier par dossier.
- Installation en production — le volume à monter, et la mise à jour.
- Versioning git — l’autre filet de sécurité.
- Import et export — sortir une entité d’une instance.