Comment empêcher les sauvegardes d’Immich de capturer un état incohérent

Évitez les sauvegardes Immich incohérentes en traitant la base de données et les fichiers multimédias comme une seule unité de récupération, dont l’ordre de capture et l’activité d’écriture sont contrôlés délibérément.

Une sauvegarde peut contenir tous les fichiers qu’elle devait copier et tout de même se restaurer incorrectement si la base de données fait référence à des ressources qui n’ont pas été capturées, ou si la copie des fichiers multimédias correspond à un moment différent de celui du catalogue. Définissez d’abord la limite de cohérence, choisissez une méthode avec arrêt ou une méthode active coordonnée, puis validez le résultat dans un environnement isolé.

Définissez l’unité de récupération avant de planifier la sauvegarde

Répertoriez la base de données PostgreSQL, les fichiers multimédias importés, les données de profil, la configuration du déploiement, les valeurs d’environnement, les secrets et tous les chemins de stockage personnalisés nécessaires pour recréer le service. Distinguez les miniatures générées, les vidéos encodées et les fichiers de modèles selon que votre politique de récupération les protège ou les régénère.

La comparaison ZimaSpace des sauvegardes Immich actives et avec arrêt explique le choix fondamental en matière de cohérence. Ce processus de prévention va un peu plus loin : quelle que soit la méthode choisie, elle doit produire un point documenté qui peut être restauré sans avoir à deviner quelle base de données correspond à quelle copie des fichiers multimédias.

Notez l’ordre de restauration à côté du périmètre de sauvegarde. Si le plan indique « restaurer les photos », sans préciser quelle sauvegarde de base de données, quelle configuration, quels identifiants et quelles correspondances de stockage reconnectent ces photos aux utilisateurs et aux albums, la définition de la sauvegarde est incomplète avant même le début de la première exécution planifiée.

Utilisez une capture avec arrêt lorsque la limite la plus simple convient

Pour un petit foyer pouvant tolérer une courte fenêtre de maintenance, suspendez les importations et arrêtez les services applicatifs qui écrivent l’état de la bibliothèque. Créez la sauvegarde de la base de données, capturez les fichiers multimédias et la configuration, puis redémarrez uniquement après que l’instantané ou la copie dispose d’un horodatage clair et d’un résultat de fin d’exécution.

Le fait d’arrêter l’application ne rend pas automatiquement un chemin incorrect utilisable. Vérifiez que l’exportation de la base de données a réussi, que les racines de fichiers multimédias prévues ont été incluses et que la destination de sauvegarde est indépendante des données actives qu’elle est censée permettre de récupérer. Notez les heures de début et de fin afin que les restaurations ultérieures puissent identifier exactement la génération concernée.

La méthode est validée lorsqu’aucune écriture applicative n’a lieu pendant la capture et qu’une restauration de test renvoie les utilisateurs, le nombre attendu de ressources, les albums et un échantillon des originaux attendus. Si l’interruption dépasse régulièrement la tolérance du foyer, passez à une méthode active coordonnée plutôt que de laisser discrètement les importations reprendre au milieu de la copie des fichiers.

Pour les sauvegardes actives, capturez la base de données et les fichiers dans un ordre connu

Lorsqu’Immich doit rester disponible, créez une sauvegarde cohérente native de la base de données plutôt que de copier le répertoire de données PostgreSQL actif comme de simples fichiers. Capturez ou prenez ensuite un instantané de l’arborescence des fichiers multimédias dans l’ordre documenté, tout en suivant les importations qui arrivent pendant la fenêtre de sauvegarde.

Le processus pratique de sauvegarde de la base de données Immich présente l’approche tenant compte de la base de données. Les commandes et les noms de conteneurs peuvent varier selon le déploiement ; le principe transférable consiste donc à demander à PostgreSQL de produire une sauvegarde cohérente plutôt qu’à faire confiance à une copie récursive en direct des fichiers de la base de données.

Privilégiez un ordre qui ne puisse pas laisser la base de données restaurée pointer vers des fichiers multimédias qui n’ont jamais été intégrés à la sauvegarde. Si la copie du système de fichiers contient des fichiers supplémentaires que la base de données ne connaît pas encore, ils peuvent être rapprochés plus sûrement que des enregistrements de base de données dont les originaux référencés sont absents. Documentez toute importation qui franchit la limite.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Coordonnez les instantanés du système de fichiers avec des hooks de base de données au lieu de supposer leur atomicité

Les instantanés du système de fichiers sont précieux, car ils capturent rapidement un volume, mais ils ne rendent pas à eux seuls cohérents sur le plan transactionnel deux systèmes qui évoluent indépendamment. Si la base de données et les fichiers multimédias résident sur des jeux de données ou des périphériques différents, définissez des hooks avant et après instantané et rendez leur synchronisation visible dans le journal de sauvegarde.

Un exemple de 2026 combinant un logiciel de sauvegarde avec des hooks d’instantané Btrfs montre pourquoi l’orchestration des instantanés nécessite des limites explicites au niveau de l’application ou de la base de données. Utilisez cette idée pour coordonner les captures ; ne recopiez pas aveuglément ses commandes de système de fichiers sur une disposition différente.

Si l’outil d’instantané ne peut pas coordonner la limite temporelle entre la base de données et les fichiers multimédias, revenez à une sauvegarde logique de la base de données accompagnée d’une sauvegarde des fichiers multimédias au lieu de prétendre disposer d’une récupération atomique. La complexité n’est justifiée que si l’exercice de restauration prouve que la capture plus rapide restitue tout de même un état cohérent de l’application.

Intégrez les tests de restauration au calendrier des sauvegardes

Une tâche de sauvegarde réussie prouve uniquement que la capture s’est terminée. Sélectionnez régulièrement une génération récente, restaurez-la sous un nom d’hôte isolé, rattachez le stockage attendu et vérifiez les utilisateurs, des originaux représentatifs, les albums, les autorisations, le fonctionnement de la recherche ainsi qu’une nouvelle sauvegarde de la base de données depuis l’instance restaurée.

La vue d’ensemble de la récupération PostgreSQL issue de la planification des sauvegardes et restaurations PostgreSQL met l’accent sur la validation de la restauration et les objectifs de récupération, plutôt que de considérer la création de la sauvegarde comme l’étape finale. Appliquez la même discipline à l’unité de récupération Immich combinée.

Considérez la politique de sauvegarde comme échouée si la restauration de la base de données réussit mais que des fichiers manquent, si les fichiers multimédias s’ouvrent sans utilisateurs ni relations, ou si la récupération dépend d’un secret stocké uniquement sur l’hôte défaillant. Corrigez le périmètre, l’ordre, la conservation ou l’indépendance avant d’augmenter la fréquence des sauvegardes ; davantage de copies incohérentes ne créent pas un point de récupération fiable.