Que faut-il restaurer ensemble pour qu'une bibliothèque photo auto-hébergée reste consultable ?
Restaurez les originaux, la base de données du catalogue et la configuration définissant les chemins comme une seule unité de récupération.
Pour une bibliothèque NAS domestique Immich, Lightroom, PhotoPrism ou similaire, les fichiers image seuls peuvent se rouvrir mais perdre les personnes, albums, évaluations, modifications, emplacements et résultats de recherche. Une récupération consultable doit aligner les fichiers médias avec la base de données ou le catalogue qui les décrit, la configuration qui mappe leurs chemins, ainsi que tout secret ou version d’application nécessaire pour lire cet état.
Définir la capacité de recherche comme plus que l’ouverture des fichiers originaux
Une bibliothèque photo est consultable lorsque l’application peut connecter chaque original à son enregistrement dans la base de données, ses métadonnées, son appartenance à un album, ses assignations de personnes et son chemin. Pouvoir ouvrir un JPEG prouve la récupération du fichier, pas celle de la bibliothèque.
Une discussion sur la récupération Immich montre que la base de données contient les emplacements des fichiers et les métadonnées de la bibliothèque tandis que les photos réelles restent dans les dossiers de téléchargement. Restaurer un seul côté peut produire des vignettes ou des enregistrements pointant vers des originaux absents.
Écrivez le résultat attendu avant la restauration : les originaux s’ouvrent, les dates de la chronologie sont correctes, les albums apparaissent, la recherche de personnes fonctionne, les modifications ou évaluations sont restituées, et les utilisateurs conservent l’accès. Ce résultat définit les composants qui appartiennent à l’unité de récupération.
Restaurer les originaux et le catalogue à partir de la même limite temporelle
L’arborescence des médias et son catalogue doivent représenter le même point de récupération. Une base de données plus récente peut référencer des fichiers manquants dans une copie média plus ancienne, tandis qu’un catalogue plus ancien peut ignorer des photos existant sur le disque.
Un cas de récupération Lightroom a nécessité une restauration en deux étapes : d’abord le dossier photo, puis une sauvegarde de catalogue correspondante datant d’avant l’incident. La même dépendance s’applique aux bibliothèques auto-hébergées qui stockent les modifications, évaluations, personnes ou albums en dehors des originaux.
Sélectionnez le timestamp commun le plus proche entre la sauvegarde média, le dump de la base de données et la copie de configuration. S’il n’existe aucun point commun, restaurez sur une instance isolée et réconciliez l’écart avant d’exposer la bibliothèque aux utilisateurs.
Préserver les chemins, identifiants et configuration qui relient les éléments
Un catalogue peut être sain et pourtant afficher des éléments manquants lorsque le chemin restauré, le nom de montage, l’identifiant de volume ou la racine de la bibliothèque diffèrent de la référence stockée. La cohérence des chemins fait donc partie de la récupération, pas d’une tâche cosmétique post-restauration.
Les utilisateurs de Lightroom rapportent que les fichiers restaurés doivent conserver les mêmes noms et la même structure de dossiers. Pour les applications conteneurisées, l’équivalent peut être un chemin de montage bind, une variable d’environnement, une URL de base de données ou une racine de stockage.
Restaurez le fichier Compose ou la configuration de l’application, les variables d’environnement, les secrets, les identifiants utilisateurs et les définitions de montage à côté de la base de données. Ne reliez pas en masse ni ne rescannez avant d’avoir confirmé quels identifiants l’application attend.
Séparer l’état requis des éléments de recherche régénérables
Les originaux, enregistrements de base de données, données utilisateur, relations d’albums, modifications et configuration sont normalement requis. Les vignettes, modèles mis en cache et certaines embeddings d’apprentissage automatique peuvent être régénérés, mais la bibliothèque peut rester lente ou partiellement non consultable tant que ces tâches ne sont pas terminées.
Un guide de déploiement Immich actuel décrit des services séparés pour le serveur, l’apprentissage automatique et la file d’attente des tâches en arrière-plan, et note une planification intégrée de sauvegarde de base de données. Ces composants expliquent pourquoi la recherche et la reconnaissance des personnes peuvent dépendre de plus que le répertoire média visible.
Documentez quels éléments générés peuvent être reconstruits et combien de temps la régénération prend. Si la reconstruction consommerait des jours de temps CPU ou si l’état du modèle original ne peut être reproduit, protégez cet élément comme partie de l’unité de récupération pratique même si l’application peut techniquement le recréer.
Faire correspondre l’état restauré à une version d’application compatible
Un catalogue ou une base de données peut nécessiter la version de l’application qui l’a créée ou migrée. Démarrer un service plus ancien avec un état plus récent, ou inversement, peut échouer avant même que les médias soient évalués.
Les utilisateurs de bibliothèques photo ont rencontré une incompatibilité de version de catalogue. Conservez le tag d’image déployé, les notes de migration et la version de la base de données afin que l’environnement de test puisse reproduire le chemin de mise à niveau attendu.
Démarrez la bibliothèque restaurée hors ligne ou sous un nom temporaire. Confirmez les migrations de base de données, la connexion utilisateur et la résolution des chemins avant d’autoriser les clients mobiles ou les tâches en arrière-plan à modifier l’état restauré.
Valider la recherche, les albums et les personnes avant la mise en production
Utilisez un test de restauration isolé qui inclut des photos anciennes et nouvelles représentatives, des éléments modifiés, plusieurs utilisateurs, des albums partagés, des métadonnées de localisation et des personnes connues. Recherchez des enregistrements dont le résultat attendu est déjà documenté.
Le plan de sauvegarde familial Immich existant de ZimaSpace fournit le contexte de planification adjacent ; ce test de restauration doit maintenant prouver que ces composants reviennent ensemble.
Basculer uniquement lorsque les originaux s’ouvrent, que les comptes correspondent, que les albums et permissions reviennent, que les résultats de recherche sont plausibles et qu’un nouvel upload s’indexe correctement. Conservez l’instance précédente et les fichiers de récupération inchangés jusqu’à ce que la bibliothèque test ait survécu à un redémarrage et à une nouvelle sauvegarde.
Produits recommandés
Assistance et conseils
Plus à lire
Pourquoi la restauration d’un volume Docker recrée-t-elle le contenu des fichiers, mais supprime-t-elle les attributs étendus ?
Un diagnostic de restauration de volume couvrant l’inventaire des xattr, les options de tar et de Rsync, les espaces de noms, la prise en...
Pourquoi un conteneur en cours d’exécution conserve-t-il son ancienne limite de mémoire après la modification du fichier Compose ?
Un diagnostic des limites mémoire couvrant les cgroups actifs, le redémarrage par rapport à la recréation, les champs Compose, les limites strictes et souples,...
Pourquoi le redémarrage d’un proxy inverse invalide-t-il toutes les sessions d’une application auto-hébergée ?
Un diagnostic de perte de session couvrant la portée des redémarrages, la propriété des cookies, la rotation des secrets, les sessions adossées au cache,...
