Quelle surcharge de stockage Immich ajoute-t-il aux données sources ?

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

How Much Storage Overhead Does Immich Add Beyond Source Data?

Immich n’applique aucun pourcentage de stockage universel ; la surcharge dépend principalement du nombre d’éléments, de la proportion de vidéos, des paramètres des fichiers dérivés, de la croissance de la base de données et des sauvegardes conservées.

Une photothèque familiale d’un téraoctet dominée par les photos ne ressemblera pas à une autre dominée par de longues vidéos de téléphone. Planifiez le stockage en mesurant chaque catégorie générée après une importation représentative, puis prévoyez une marge distincte pour la croissance, les traitements temporaires et les copies de récupération.

Les fichiers multimédias dérivés constituent généralement la plus grande surcharge visible

Immich prépare des images plus petites pour les frises chronologiques et les visionneuses, et peut créer des versions encodées des vidéos pour une lecture compatible. Ces fichiers dépendent du nombre d’éléments, de la résolution, des paramètres de qualité, ainsi que de la durée et des codecs des vidéos. Ils s’ajoutent aux fichiers originaux, même lorsque les utilisateurs ne les téléchargent jamais directement.

Une mesure réalisée par la communauté sur une bibliothèque externe de 772 Gio indiquait environ 18 Gio de miniatures et 65 Gio de vidéos encodées. Cette observation d’environ 83 Gio constitue un exemple chiffré utile, et non un ratio de planification, car la proportion de photos et de vidéos ainsi que les paramètres peuvent modifier considérablement ces deux composantes dans une autre bibliothèque.

Relevez la taille des répertoires de miniatures et de vidéos encodées après avoir importé un échantillon représentatif contenant les vraies photos du foyer, les fichiers RAW, les courtes séquences et les longues vidéos. Calculez séparément chaque catégorie dérivée par rapport au nombre d’éléments et aux octets sources. Les ratios fondés sur le nombre d’éléments et ceux fondés sur les octets répondent à des questions de croissance différentes.

La base de données et l’état de recherche évoluent avec les relations

La surcharge de la base de données provient des enregistrements d’éléments, des utilisateurs, des albums, des métadonnées, des visages, des représentations de recherche, des index et de l’état des tâches. Une petite image et une grande vidéo peuvent générer un nombre similaire de certains enregistrements malgré des tailles sources très différentes. La croissance de la base de données est donc davantage liée aux entités et aux fonctionnalités activées qu’au nombre initial de téraoctets.

L’article de ZimaSpace consacré aux sauvegardes Immich distingue les originaux essentiels et l’état de la base de données des chemins dérivés qui peuvent être reconstruits. Cette distinction est importante pour les prévisions : supprimer les fichiers dérivés peut libérer temporairement de l’espace, tandis que la perte de la base de données modifie les relations que les miniatures ne peuvent pas reconstituer.

Relevez la taille de la base de données avant et après l’importation d’un groupe connu, puis notez les fonctionnalités de traitement qui sont terminées. Répétez la mesure une fois les traitements des visages et de la recherche achevés. Ne faites pas de projection à partir d’une file d’attente inachevée, car la surcharge apparente par élément augmentera à mesure que d’autres représentations et relations seront enregistrées.

Les sauvegardes et les traitements temporaires modifient le seuil de capacité

Un total courant exclut l’espace nécessaire pendant la création des sauvegardes, l’exportation des bases de données, la préparation des importations ou le remplacement des fichiers dérivés. Lors d’une mise à niveau ou d’une régénération, les anciens et les nouveaux fichiers peuvent coexister. Un disque dimensionné exactement selon l’utilisation habituelle peut donc échouer pendant une maintenance ordinaire, même si la croissance annuelle des médias reste modeste.

Un article consacré à la planification du stockage décrit un scénario dans lequel Immich remplit un SSD auparavant peu utilisé avec les originaux, les miniatures, les métadonnées et les traitements d’apprentissage automatique. La leçon générale est que la croissance de l’application et les copies de récupération se disputent la marge opérationnelle : l’espace libre doit donc couvrir la situation de maintenance la plus exigeante, et non l’état actuel au repos.

Conservez la rétention des sauvegardes comme un poste distinct, car les copies hors hôte protègent contre un autre type de défaillance. Prévoyez également une marge de fonctionnement mesurée à partir de l’importation, du réencodage ou du test de mise à niveau le plus volumineux. Davantage d’espace inutilisé n’est pas automatiquement préférable, mais une marge maximale mesurée nulle rend les problèmes de capacité prévisibles.

-15% OFF

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

Single board computer zimaboard2

Créez une feuille de calcul de surcharge propre à votre bibliothèque

Créez des lignes pour les originaux, les miniatures et les aperçus, les vidéos encodées, la base de données, les fichiers d’apprentissage automatique, les vidages de sauvegarde locaux et l’espace temporaire maximal. Mesurez une base vide, puis importez un groupe représentatif. Attendez la fin des files d’attente et relevez à nouveau chaque ligne avant de calculer les écarts.

Une discussion de praticiens sur le placement sur SSD et HDD distingue les données générées sensibles à la latence des originaux volumineux. Pour le dimensionnement de la capacité, cette distinction permet de garder visible la surcharge du niveau rapide, même lorsque les originaux résident ailleurs ; sinon, le total important du NAS peut masquer un SSD applicatif presque plein.

Répétez l’opération avec le groupe afin d’obtenir une plage plutôt qu’un seul ratio. Projetez chaque ligne selon le facteur approprié : nombre d’éléments, octets ou durée des vidéos, croissance des utilisateurs et des relations, nombre de versions conservées ou traitements de maintenance maximaux. N’ajoutez la croissance prévue des sources qu’une fois les besoins dérivés et de récupération clairement visibles séparément.