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.