Sauvegarde du catalogue - Prudence si vous ne passez pas par LR

[Samoreen]

Pour info.

Si vous faites comme moi partie de ceux qui considèrent (considéraient) que les catalogues LR sont une donnée comme une autre et que vous les avez intégrés purement et simplement aux routines de sauvegarde de vos données au même titre que d'autres documents, vos données LR ne sont pas nécessairement sauvegardées correctement.

Jusqu'à récemment, je me contentais de sauvegarder le(s) fichier(s) .lrcat qui est le seul fichier nécessaire en cas de corruption ou de perte du catalogue courant. Cette approche n'est plus valable. Il faut intégrer le dossier lrcat-data dans vos sauvegardes. Explications...

Depuis l'apparition des fonctions liées à l'IA et la disparition du fichier DNG intermédiaire en cas de débruitage IA, tous les (très volumineux) blocs de données nécessaires à la réversibilité de ces opérations sont stockées dans le dossier lrcat-data sous forme de fichiers xxxx.blob. Ce dossier est maintenant inclus dans les backups réalisés avec LR, ce qui augmente considérablement la taille des sauvegardes. On ne peut donc plus se contenter de sauvegarder uniquement le fichier .lrcat. Si ces "blobs" ne sont pas disponibles, aucune opération utilisant l'IA ne pourra être réversible. Il semblerait même que LR ne soit pas capable de gérer cette situation. On notera cependant que la commande d'optimisation du catalogue semble, d'après ce que j'ai observé, faire un peu de ménage dans le dossier lrcat-data.

Pour compliquer les affaires, il semble bien qu'un bug vienne amplifier le problème. Ces "blobs" de données binaires sont dupliqués (a priori indûment) dans les fichiers XMP, eux-mêmes dupliqués dans une des tables de la base de données SQLite (le fichier .lrcat). Ce qui fait que le fichier lrcat croît en volume de concert avec les fichiers .blob qui apparaissent dans le dossier lrcat-data. Cela conduit à des fichiers lrcat très volumineux et à des sauvegardes de plus en plus encombrantes. On cite ici et là des chiffres frôlant les 5 ou 10 Go.

Vous pouvez observer ce phénomène en regardant la taille des fichiers XMP correspondant aux images pour lesquelles vous avez utilisé le débruitage IA et/ou les différentes fonctionnalités IA. C'est parfois totalement extravagant.

On peut toujours renoncer aux fichiers XMP mais ce n'est pas conseillé. C'est le seul moyen de récupérer les modifications réalisées sur une image quand le catalogue est perdu.

On attend une réponse d'Adobe sur cette question mais j'ai bien peur qu'ils considèrent ça plus comme une fonctionnalité que comme un problème.

C'est l'IA. Ça coûte déjà cher en stockage, en mémoire et en énergie lors de l'apprentissage mais même pendant une utilisation locale, les besoins en espace disque sont en croissance exponentielle. Il suffit de regarder l'espace occupé par les applications elles-mêmes après leur installation.

[Alain c]

J'ai recement acheté un nouveau PC avec 5 TO de mémoire au total, en plus de mes disques extreieurs de sauvegarde; histoire de voir venir.
Donc je sauvegarde pas uniquement le fichier .lrcat, mais tout les autres: lrcat-data, sync.lrdata, previews.lrdata, et Helper.data
Et je fais 2 sauvegardes de mon catalogue en cours.
 
Ce qu'il faut faire de temps en temps c'est de lancer LR à partir d'une de ses sauvegardes pour voir si elles ne sont pas corrompues, ça m'est arrivé d'avoir une sauvegarde corrompue;  (je garde mles 2 derniers catatlogues).

[MFloyd]

Mon système de sauvegarde couvre LrC de 3 façons: (1) par le système de sauvegarde inhérent à Lightroom, tel que décrit supra; (2) par CCC (Carbon Copy Cloner) qui sauvegarde toutes les données, périphériques comprises; (3) par Time Machine. Une sauvegarde continue, dans le cloud, est en évaluation utilisant Arq7 pour la sauvegarde et BackBlaze comme repositoire.

[jla46]

La méthode exposée par MFloyd est un peu redondante, mais bonne. C'est d'ailleurs un peu ce que je fais (mais sur un NAS, pas sur le Cloud)

[ChatOuille]

Je n'ai jamais testé une sauvegarde. Je fais (à tort) confiance. Je fais régulièrement une sauvegarde du catalogue + vérification à partir de LR. C'est essentiel.
Régulièrement je fais une sauvegarde d'un tas de dossiers, donc de la sauvegarde primaire de LR. Il va de soi qu'un tas de dossiers, donc les previews sont repris, ainsi que les photos, etc. Je me sens ainsi protégé à 99% car on ne peut jamais dire 100%.

[restoc]

Depuis l'apparition des fonctions liées à l'IA et la disparition du fichier DNG intermédiaire en cas de débruitage IA, tous les (très volumineux) blocs de données nécessaires à la réversibilité de ces opérations sont stockées dans le dossier lrcat-data sous forme de fichiers xxxx.blob. Ce dossier est maintenant inclus dans les backups réalisés avec LR, ce qui augmente considérablement la taille des sauvegardes. On ne peut donc plus se contenter de sauvegarder uniquement le fichier .lrcat. Si ces "blobs" ne sont pas disponibles, aucune opération utilisant l'IA ne pourra être réversible. Il semblerait même que LR ne soit pas capable de gérer cette situation. On notera cependant que la commande d'optimisation du catalogue semble, d'après ce que j'ai observé, faire un peu de ménage dans le dossier lrcat-data.

Pour compliquer les affaires, il semble bien qu'un bug vienne amplifier le problème. Ces "blobs" de données binaires sont dupliqués (a priori indûment) dans les fichiers XMP, eux-mêmes dupliqués dans une des tables de la base de données SQLite (le fichier .lrcat). Ce qui fait que le fichier lrcat croît en volume de concert avec les fichiers .blob qui apparaissent dans le dossier lrcat-data. Cela conduit à des fichiers lrcat très volumineux et à des sauvegardes de plus en plus encombrantes. On cite ici et là des chiffres frôlant les 5 ou 10 Go.

Merci pour cette info essentielle.
J'envisageai de reprendre un abonnement LR mais ce genre de chose fait froid dans le dos quand on a un gros catalogue et donc une énorme quantité d'images et qu'on utilise l'IA assez fréquemment pour des détourages etc.

Y a t-il eu des progrés depuis février ?

[Samoreen]

Y a t-il eu des progrés depuis février ?

Oui. Le mécanisme de collecte des données nécessaires à l'inversion des opérations AI Masks, Denoise et Super Resolution a été modifié. Les fichiers blob ne sont plus indûment recopiés dans les fichiers XMP et les données sont stockées dans des fichiers compagnons séparés des fichiers XMP. Ces fichiers ont l'extension acr et il faut bien sûr les inclure dans la sauvegarde de vos photos au même titre que les XMP. Il y a encore des fichiers blob qui traînent dans le dossier lrcat-data et qui survivent à une optimisation du catalogue mais ils sont plus rares.

Les fichiers XMP sont donc revenus à une taille plus raisonnable et le catalogue est moins chargé mais il y a maintenant les fichiers .acr qui accompagnent les photos et qui restent nécessaires.

La conclusion reste la même : l'IA n'a pas fini de vous coûter cher en ressources (disques, mémoire et puissance machine). Financièrement, il va falloir songer à éviter la bulle boursière qui s'annonce en commençant à rémunérer l'IA à son coût réel. Ça a déjà commencé avec certains logiciels de post-traitement (par ex. les outils Topaz) et les dérèglements actuels ne vont pas inverser la tendance. Le photographe qui passe un peu de temps à faire des prises de vue soignées va faire de grosses économies.

[restoc]

Merci pour tous ces détails qui ne se trouvent pas facilement sans faire d'essais pousés et qui peuvent vite mettre le bazars sur des grosses archives si on a la mauvaise idée de reprendre des PT avec l'IA ... On imagine qu'il n' y a pas de notice d'avertissement sur les conséquences avant de faire un upgrade.

Pour info, titre de retour de service comme à Roland Garros ... Je viens de regarder ce que fait DXO DPL9 : Sur un Fichier Nikon RAw  son  fichier DOP qui inclut les descriptifs de traitements fait 10,6 KO sur le raw brut, puis 11,5Ko avec deux masques IA ( un masque animal et un masque arrière plan). Donc DXO n'enregistre que le descriptif des commandes pas un plan raster des contours. Puis j'ai créé un masque au pinceau que je pensais un bit plan( raster) et le fichier DOP ne croit que de 1,0ko. Ensuite j'ai créé en plus du DOP un XMP qui inclut tout sauf le fichier image évidemment et celui a une taille de 92 ko. A ce niveau çà reste acceptable. Maintenant il faudrait comparer à TT d'IA semblable ( détourage, créatif etc ).

[Samoreen]

Donc DXO n'enregistre que le descriptif des commandes pas un plan raster des contours.

C'est effectivement plus léger mais je pense que cela résulte pour DxO d'une gestion nettement plus simpliste à la fois de la base de données et des masques. La simple comparaison de la structure des bases de données respectives de LR et DPL (toutes deux SQLite) montre que dans DPL on est loin du niveau de sophistication de la BD de LR (ce qui explique le gros écart entre LR et DPL en termes de fonctionnalités DAM).

En outre, la gestion simplifiées des masques dans DPL entraîne quelques inconvénients notables. Le plus flagrant est l'obligation de faire toutes les corrections optiques avant de créer un masque. DPL ne sait pas corriger la position et les limites d'un masque quand on modifie quoi que ce soit dans la perspective ou quand on applique des corrections optiques. Si on change d'avis après coup, les masques sont à refaire.

[restoc]

C'est clair que DXO  a cette contrainte de corrections géométriques qui doivent se faire soit au début soit à la fin du développement d'une image .

Mais la contrainte est faible vis à vis du service rendu et de la simplicité pour les grosses rafales où le sujet change de place et de forme d'une image à l'autre: On crée les masques IA sur la premiére image et il les replace/déforme parfaitement sur toute la série. On a donc une seule contrainte sur la premiére image mais plus aucune sur les 300 ou 600 d'un beau vol de paf,les masques se recalculent parfaitement que ce soit en batch ou image par image. Pour un logiciel de développement c'est  bien adapté aux mitrailleuses modernes et sans soucis pour des workflows courants et sans prise de tête pour les sauvegardes.

Chaque logiciel a son champ de compétences et de contraintes.

[Samoreen]

un beau vol de paf

Oups! Ça doit être intéressant à observer .