En résumé
Une sauvegarde complète, c’est d’abord le dossier de données — y compris le fichier secret.key, la clé de chiffrement sans laquelle les mots de passe de bases et les jetons git restaurés seraient illisibles. S’y ajoute ce qui vit ailleurs : la clé secrète de connexion, la clé de chiffrement si vous la fournissez vous-même, et la base PostgreSQL si vous en utilisez une.
Ce qu’il faut sauvegarder
Le dossier de données contient presque tout ; trois choses peuvent vivre en dehors, selon votre configuration.
Hors du dossier
Une sauvegarde sans la clé de chiffrement est une sauvegarde incomplète
Restaurez la base applicative sans secret.key — ou sans la LINKR_ENCRYPTION_KEY que vous fournissiez — et l’instance remontera, vos utilisateurs se reconnecteront, mais chaque mot de passe de base mémorisé, chaque jeton git et chaque secret de connexion sera illisible, sans erreur visible, et devra être ressaisi à la main. La clé secrète de connexion, elle, se remplace sans dommage : au pire, tout le monde se reconnecte. Voir Configuration.
Votre sauvegarde contient donc une clé
Par défaut, l’archive du dossier réunit les secrets chiffrés et la clé qui les ouvre. Protégez-la comme les secrets eux-mêmes : accès restreint, archive chiffrée. Si votre politique l’interdit, fournissez la clé par LINKR_ENCRYPTION_KEY et sauvegardez-la séparément — la base seule, alors, ne déchiffre plus rien.
Ce que vous pouvez exclure
Les caches sont reconstructibles. Les exclure allège considérablement la sauvegarde ; au pire, la première construction d’environnement après restauration sera plus longue. Seule réserve : sur une instance sans accès réseau, gardez _duckdb_ext/, que le serveur ne pourrait pas retélécharger.
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 — secret.key compris —, fournissez les mêmes variables d’environnement, 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é de chiffrement 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, pas plus qu’une base que Linkr a créée dans un dossier du serveur plutôt que dans son propre dossier — l’un et l’autre relèvent 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.