Dernier blog

N’augmentez pas d’abord max_connections. Mesurez les sessions Immich, totalisez la demande de chaque conteneur, préservez une marge pour l’administration et n’optimisez que le goulot d’étranglement avéré.

Séparez les tâches répétées des ressources en double. Utilisez un chemin d’ingestion canonique, contrôlez les nouvelles tentatives et les changements de chemin, puis testez la réintégration sur une petite cohorte.

Ne supprimez jamais les journaux WAL de PostgreSQL pour libérer de l’espace. Arrêtez les écritures d’Immich, préservez l’état de la base de données, ajoutez de la capacité en toute sécurité, récupérez PostgreSQL, puis évitez que le...

Immich ne doit pas recréer silencieusement les originaux sources manquants. Identifiez le type de fichier régénéré et le logiciel qui l’a généré, puis corrigez l’identité de création.

Commencez par identifier le chemin qui a changé : les racines de médias gérées et les chemins d’importation de bibliothèques externes ont des comportements différents en matière de migration et de données obsolètes.

Conservez l’ancien hôte Immich intact jusqu’à ce que le serveur restauré ait démontré son identité, ses médias, ses relations, ses écritures et ses redémarrages, ainsi que la création d’une nouvelle sauvegarde récupérable en conditions réelles.

Une architecture Immich répartie fonctionne souvent bien : SSD pour la base de données et les données générées fréquemment consultées, HDD pour les originaux, chaque chemin étant dimensionné, sauvegardé et testé après redémarrage.

La sauvegarde peut déclencher des tâches liées au processeur, au machine learning, à la vidéo, aux bases de données et aux disques une fois les téléversements terminés. Adaptez la vitesse du ventilateur à la file d’attente...