Faut-il stocker les métadonnées d’Immich sur un SSD et les données volumineuses sur un disque dur ?

Oui, un déploiement d’Immich bénéficie souvent du fait de conserver la base de données et les données générées sensibles à la latence sur un SSD, tout en stockant les fichiers photo et vidéo originaux volumineux sur un disque dur, en particulier lorsque la bibliothèque est bien plus grande que l’état de l’application. Cette séparation n’est utile que si les chemins, les marges d’espace libre, les sauvegardes et les étapes de récupération restent clairs.

La question n’est pas « métadonnées rapides, médias lents ». Immich sollicite différemment plusieurs rôles de stockage : PostgreSQL gère de nombreuses petites opérations sur l’état ; les miniatures et les aperçus sont fréquemment lus pendant la navigation ; les vidéos encodées peuvent être volumineuses ; les originaux privilégient la capacité et la durabilité. Mesurez séparément ces rôles avant de déplacer quoi que ce soit.

Séparez l’état actif, de petite taille et riche en E/S, des médias axés sur la capacité

Inventoriez les données PostgreSQL, les miniatures, les aperçus, les vidéos encodées, le cache des modèles, les originaux importés, les bibliothèques externes et les copies de sauvegarde. Notez la taille actuelle, la croissance, la fréquence de lecture et d’écriture, le coût de reconstruction et la nécessité, pour chaque rôle, de survivre à une restauration. Vous éviterez ainsi qu’une étiquette générique de dossier « métadonnées » masque plusieurs charges de travail très différentes.

Le framework de stockage ZimaSpace pour placer les métadonnées des médias et le cache actif établit une distinction utile : les bases de données et les index bénéficient d’un stockage à faible latence, tandis que les médias sources volumineux peuvent rester sur un stockage capacitif lorsque leur mode d’accès ne nécessite pas les mêmes IOPS. Si votre disque dur actuel présente une faible latence lors des recherches, de la navigation dans la timeline et des tâches en arrière-plan, déplacer chaque fichier dérivé vers un SSD pourrait n’apporter qu’un gain limité pour l’utilisateur. Conservez la configuration actuelle jusqu’à ce qu’une comparaison contrôlée montre que le chemin de stockage actif est réellement en attente.

Placez PostgreSQL et les fichiers dérivés fréquemment lus sur un SSD lorsqu’ils constituent le goulot d’étranglement

PostgreSQL et la navigation intensive dans les miniatures génèrent de nombreuses petites lectures et écritures qui peuvent sembler lentes sur un disque mécanique sollicité, notamment lorsque les importations ou les sauvegardes utilisent le même périphérique.

Pour les configurations actuelles d’Immich, conservez la base de données sur un stockage local à faible latence et déplacez délibérément les chemins de données générées pris en charge, plutôt que d’inventer des points de montage imbriqués arbitraires.

Le mécanisme de stockage est bien compris en dehors d’Immich : le réglage du stockage PostgreSQL bénéficie d’un accès aléatoire bien moins coûteux que celui des disques rotatifs. Cela ne garantit pas un gain visible dans Immich, mais explique pourquoi la base de données et les index sont de bons candidats pour un SSD lorsque la latence du périphérique est le temps d’attente mesuré.

Mesurez l’amélioration avec le même échantillon d’albums, de recherches et d’importations avant et après. Si la latence de la base de données diminue, mais que la requête visible par l’utilisateur attend toujours le transfert réseau, le décodage des images ou l’apprentissage automatique, cessez d’attribuer le délai restant au disque dur.

Conservez les originaux sur un disque dur lorsque la capacité et la protection priment sur les E/S aléatoires

Les photos et vidéos originales constituent généralement la catégorie de stockage la plus volumineuse et sont souvent lues sous forme de fichiers entiers plutôt que de petites pages aléatoires de base de données. De grands pools de disques durs peuvent donc convenir aux originaux lorsqu’ils offrent la fiabilité, le débit et la capacité de sauvegarde nécessaires. Le niveau disque dur doit néanmoins disposer d’espace libre et conserver une latence saine lors des importations et de la navigation simultanées.

Une longue discussion sur le stockage Immich concernant la séparation des miniatures et des médias reflète le même besoin opérationnel : les ressources générées pour la navigation et les originaux volumineux ont des priorités d’accès différentes. Elle ne prouve pas que chaque installation nécessite deux périphériques physiques ; le gain dépend de l’endroit où les requêtes attendent actuellement.

Ne placez pas les originaux irremplaçables sur un disque dur simplement parce qu’il est moins cher, puis ne considérez pas le RAID comme une sauvegarde. Conservez une deuxième copie ainsi qu’une copie hors hôte ou hors ligne, conformément à l’objectif de protection du foyer. La répartition des niveaux de stockage modifie les performances et le coût ; elle ne réduit pas les conséquences de la perte de l’unique copie de la bibliothèque familiale.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Migrez un seul rôle de stockage à la fois et testez les points de montage après redémarrage

Avant de déplacer un chemin, effectuez une sauvegarde cohérente de la base de données et notez la correspondance actuelle des points de montage entre l’hôte et les conteneurs. Déplacez un seul rôle, démarrez la pile, vérifiez les anciennes et les nouvelles ressources, effectuez une recherche, lisez une vidéo, importez un fichier sans importance et confirmez que les nouvelles écritures arrivent sur le périphérique prévu. Ne déplacez pas la base de données, les miniatures, les originaux et les destinations de sauvegarde dans une seule opération.

Redémarrez l’hôte au lieu de simplement recréer les conteneurs. Une configuration répartie fonctionnelle met les points de montage SSD et disque dur en ligne avant toute écriture d’Immich, conserve les utilisateurs et les relations, lit des originaux échantillonnés et maintient la surveillance de l’espace libre sur les deux niveaux. Un répertoire de remplacement vide à un point de montage attendu est un motif d’arrêt. Conservez la séparation lorsque le goulot d’étranglement mesuré s’améliore et que la procédure de récupération reste compréhensible. Revenez en arrière si la configuration introduit des chemins obsolètes, des ressources manquantes, une dérive des permissions ou un processus de sauvegarde qui ne protège qu’un seul niveau. La meilleure conception de stockage est la plus rapide que vous puissiez encore restaurer correctement.