Comment réparer Immich après le remplissage de son volume de base de données

Lorsque le volume de la base de données Immich est plein, arrêtez les nouvelles écritures d’Immich, préservez le répertoire de données PostgreSQL et libérez un espace de travail sûr avant toute tentative de récupération. Ne supprimez pas de fichiers dans pg_wal ou dans d’autres éléments internes de PostgreSQL simplement parce qu’ils sont volumineux.

Un système de fichiers de base de données plein peut interrompre les points de contrôle ou la récupération après incident. Les redémarrages répétés peuvent donc continuer à échouer même si l’application photo elle-même semble fonctionner correctement. Commencez par déterminer précisément quel système de fichiers est plein — données PostgreSQL, stockage racine de Docker, mémoire partagée ou autre point de montage — puis réparez cette couche sans détruire les éléments dont vous pourriez avoir besoin pour revenir en arrière.

Confirmer quel système de fichiers est plein et arrêter les écritures supplémentaires

Vérifiez la disponibilité en octets et en inodes pour le point de montage PostgreSQL, la racine des données Docker, le système de fichiers racine de l’hôte et tout chemin tmpfs ou de mémoire partagée mentionné dans l’erreur. Faites correspondre l’horodatage avec les journaux PostgreSQL. Un message « no space left on device » provenant de pg_wal indique un problème différent d’un cache d’images ou d’une partition de miniatures pleine.

Une discussion sur la récupération d’une base de données Immich montre PostgreSQL interrompant la récupération parce qu’il ne pouvait pas écrire un fichier WAL temporaire après saturation du stockage. Le cas est ancien et dépend du déploiement, mais il montre pourquoi modifier les permissions des fichiers ou redémarrer la pile ne répare pas un problème de capacité.

Mettez en pause les téléversements et les tâches en arrière-plan, puis arrêtez les composants de l’application qui génèrent de nouvelles opérations sur la base de données. Conservez la première séquence de journaux ayant échoué ainsi que la carte des points de montage. Si le système de fichiers plein n’est pas celui des données PostgreSQL, réparez le véritable emplacement au lieu de déplacer inutilement la base de données.

Préserver l’état de PostgreSQL avant de libérer de l’espace

Une fois PostgreSQL arrêté, créez un instantané du système de fichiers ou une copie complète du répertoire de données de la base lorsque le stockage et les outils le permettent. Incluez le répertoire WAL et tous les espaces de tables non standard dans un même état. Cette copie de sécurité vous permet de revenir au point de l’incident si la prochaine tentative de récupération aggrave la situation.

Les recommandations de récupération PostgreSQL en cas de manque d’espace disque énoncent clairement la règle essentielle : le WAL participe à la cohérence de la base de données, ce n’est pas un simple amas de journaux, et le supprimer manuellement peut corrompre la base. Créez plutôt de la capacité en agrandissant ou en déplaçant le volume, ou en supprimant des données non liées dont la suppression est sûre. Ne remplacez pas immédiatement la base de données défaillante par la dernière sauvegarde, sauf si vous avez décidé que l’état actuel est irrécupérable et acceptez de perdre les modifications effectuées depuis cette sauvegarde. Préserver l’instance saturée vous fournit à la fois un point de retour et des éléments permettant de comprendre pourquoi l’espace a disparu.

Récupérer PostgreSQL en premier, puis déterminer si Immich doit être réparé

Une fois suffisamment d’espace disponible, démarrez PostgreSQL seul ou avec la pile minimale requise et surveillez les journaux de récupération. Un démarrage propre, une vérification d’état réussie et un accès normal en lecture sont des indicateurs plus fiables que l’état « running » d’un conteneur. Créez une nouvelle sauvegarde native de la base dès qu’elle est suffisamment stable pour le permettre.

Le guide de ZimaSpace sur la maintenance ou le remplacement d’une base de données Immich fournit le repère suivant : les problèmes courants de taille ou de performances ne doivent pas entraîner une reconstruction, tandis qu’un échec récurrent d’intégrité ou de récupération peut justifier la restauration d’une copie vérifiée de la base de données.

Ne démarrez Immich qu’après avoir vérifié que PostgreSQL reste sain.

Vérifiez les utilisateurs, la chronologie, plusieurs originaux, les albums, la recherche et un nouveau téléversement contrôlé. Si la base de données démarre mais que les requêtes de l’application échouent systématiquement, conservez les nouveaux journaux et déterminez si le problème actif concerne désormais la compatibilité du schéma ou de la version, ou l’intégrité des données — et non plus l’espace libre.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Corriger la cause de la croissance et vérifier que le système peut à nouveau se remplir sans danger

Mesurez ce qui a augmenté : tables normales de la base de données, rétention du WAL, sauvegardes stockées sur le même volume, journaux, couches Docker ou chemin inattendu. Si l’incident provient d’un flux d’archivage ou de réplication défaillant, ou d’un autre service qui écrit dans le volume de la base de données, corrigez cette cause au lieu d’augmenter simplement la capacité.

Configurez des alertes bien avant que le volume n’atteigne le point où PostgreSQL ne peut plus effectuer de point de contrôle ou récupérer son état. Surveillez à la fois le pourcentage et l’espace libre absolu : un grand volume peut avoir un faible pourcentage d’espace libre tout en conservant suffisamment d’espace de travail, tandis qu’un petit volume de base de données peut devenir rapidement dangereux. Conservez les sauvegardes de la base de données en dehors de la même zone de défaillance que celle qu’elles protègent.

Enfin, répétez un cycle normal de téléversement et de traitement en arrière-plan, créez une nouvelle sauvegarde de la base de données, redémarrez la pile et redémarrez l’hôte. Le système est rétabli si la diminution de l’espace libre reste stable, qu’aucune erreur WAL ou de récupération n’apparaît, que les anciens et nouveaux éléments sont lisibles et qu’un seuil documenté déclenche une intervention avant que les écritures ne cessent à nouveau.