Dat gaat ook op voor de back-up die Lightroom (Classic) zelf (standaard) maakt wanneer je het programma afsluit:
Bij de komst van Lightroom (Classic) 7.3 is er een probleem aan het licht gekomen die rechtvaardigt om hier eens wat dieper op in te gaan.
Allereerst nog even over de back-up optie zelf. Wanneer je bovenstaand vraag niet krijgt bij het afsluiten van je catalogus dan heb je dit (misschien ongemerkt) uitgezet. Je kunt het weer ‘aanzetten’ onder het menu ‘Bewerken’ en dan ‘Catalogusinstellingen’ onder het tabblad ‘Algemeen’:
Dit gedrag kun je overigens per catalogus bepalen dus mocht je meer dan 1 catalogus gebruiken (niet geadviseerd) dan moet je dit dus meerdere keren doen.
Deze back-up betreft overigens ALLEEN de Lightroom catalogus en dus NIET de foto’s zelf! Daarvan moet (altijd al) separaat een back-up worden gemaakt. De waarschuwing hierover, bovenaan in het dialoogscherm, zien mensen vaak over het hoofd.
Toch is een back-up van je catalogus net zo belangrijk als van je foto’s zelf. Al je bewerkingen en organisatie is er namelijk in opgeslagen. Al het werk dus dat je in de loop van de jaren aan je collectie hebt uitgevoerd.
Stap 4.
Bij de komst van Lightroom (Classic) 7.3 is er een probleem aan het licht gekomen die rechtvaardigt om hier eens wat dieper op in te gaan.
Allereerst nog even over de back-up optie zelf. Wanneer je bovenstaand vraag niet krijgt bij het afsluiten van je catalogus dan heb je dit (misschien ongemerkt) uitgezet. Je kunt het weer ‘aanzetten’ onder het menu ‘Bewerken’ en dan ‘Catalogusinstellingen’ onder het tabblad ‘Algemeen’:
Dit gedrag kun je overigens per catalogus bepalen dus mocht je meer dan 1 catalogus gebruiken (niet geadviseerd) dan moet je dit dus meerdere keren doen.
Deze back-up betreft overigens ALLEEN de Lightroom catalogus en dus NIET de foto’s zelf! Daarvan moet (altijd al) separaat een back-up worden gemaakt. De waarschuwing hierover, bovenaan in het dialoogscherm, zien mensen vaak over het hoofd.
Toch is een back-up van je catalogus net zo belangrijk als van je foto’s zelf. Al je bewerkingen en organisatie is er namelijk in opgeslagen. Al het werk dus dat je in de loop van de jaren aan je collectie hebt uitgevoerd.
Een goed werkende, niet corrupte catalogus is dan ook enorm belangrijk. Wanneer je een reguliere back-up hebt ingeregeld waarin niet alleen je foto’s maar ook je Lightroom catalogus (catalogi) mee neemt dan ben je al vrij veilig. De Back-up die Lightroom voor je kan maken bij het afsluiten is dan ook een extra maatregel die:
1. De staat van de catalogus van dat moment vastlegt
Zodat je terug kunt naar een eerder moment, wanneer je bijvoorbeeld per ongeluk iets doet dat niet eenvoudig kan worden hersteld
2. De integriteit van de database test
Hiermee wordt gecontroleerd of de catalogus beschadigd is voordat Lightroom de back-up voltooid
3. Die de catalogus optimaliseert
De database wordt opgeschoond en opnieuw ingedeeld ten behoeve van de performance
4. Die het bestand (de .lrcat) inpakt zodat die minder ruimte in beslag neemt.
Mijn Master Catalogus van 1,25 Gb neemt ingepakt als .zip bestand ‘maar’ 510 Mb ruimte in beslag.
Nadat versie 7.3 van Lightroom werd geïntroduceerd bleek dat deze de back-up niet (altijd) goed uitvoerde. Mensen die van deze back-up afhankelijk waren zijn hier toen op een pijnlijke manier achter gekomen. Ze wisten dus pas op het moment dat ze hem nodig hadden dat de back-up defect was. Hoe kun je nu voorkomen dat je in zo'n situatie terecht komt?
De beste manier (bij back-ups in z'n algemeen, niet alleen Lightroom) is om back-ups met enige regelmaat te testen. Dat kan op verschillende manieren:
TEST 1: Lightroom Back-up catalogus openen met Lightroom:
Een heel eenvoudige manier om een back-up catalogus te testen is om er af en toe een te openen om te zien wat er gebeurt.
Omdat de gebackupte Lighroom catalogi tegenwoordig ingepakt zijn (in het zip formaat) moet je die dan wel eerst uitpakken (In Windows gewoon rechtsklikken en ‘Alles uitpakken…’ kiezen:
De uitgepakte .LRCAT file kun je het eenvoudigste openen door erop te dubbelklikken. Lightroom start dan op met deze catalogus. In dit geval blijkt al meteen dat de back-up blijkbaar corrupt is:
Lightroom sluit vervolgens af en wanneer je hem weer probeert te openen zie je onderstaande dialoogscherm. De optie ‘Catalogus herstellen’ is hoopgevend…
Toch blijkt dat er echt niets meer aan te doen is:
Je zult in dit geval moeten uitwijken naar een andere (eerdere) back-up. In dit geval is het maar een test en ben ik dus niet echt afhankelijk van deze back-up, gelukkig maar.
TEST 2: Database onderzoeken
Een alternatieve manier waarbij je de catalogus echt aan een nader (technisch) onderzoek onderwerpt is met tooling die de onderliggende SQLite database analyseert. Daarbij twee opmerkingen:
1. Hiermee kunnen fouten worden ontdekt die Lightroom zelf heeft gemist bij zijn integriteitstest. Een catalogus waar Lightroom geen problemen ziet kan dus toch corruptie bevatten.
2. Andersom zal deze test de Lightroomspecifieke testen (die Lightroom zelf uitvoert) niet doen. Het kan dus zijn dat Lightroom zelf fouten ontdekt die niet naar voren komen bij deze integriteitscontrole op databaseniveau.
Met andere woorden: beide testen moeten succesvol zijn. Wanneer één van beide faalt dan heb je een probleem.
Stap 1.
1. De staat van de catalogus van dat moment vastlegt
Zodat je terug kunt naar een eerder moment, wanneer je bijvoorbeeld per ongeluk iets doet dat niet eenvoudig kan worden hersteld
2. De integriteit van de database test
Hiermee wordt gecontroleerd of de catalogus beschadigd is voordat Lightroom de back-up voltooid
3. Die de catalogus optimaliseert
De database wordt opgeschoond en opnieuw ingedeeld ten behoeve van de performance
4. Die het bestand (de .lrcat) inpakt zodat die minder ruimte in beslag neemt.
Mijn Master Catalogus van 1,25 Gb neemt ingepakt als .zip bestand ‘maar’ 510 Mb ruimte in beslag.
Nadat versie 7.3 van Lightroom werd geïntroduceerd bleek dat deze de back-up niet (altijd) goed uitvoerde. Mensen die van deze back-up afhankelijk waren zijn hier toen op een pijnlijke manier achter gekomen. Ze wisten dus pas op het moment dat ze hem nodig hadden dat de back-up defect was. Hoe kun je nu voorkomen dat je in zo'n situatie terecht komt?
De beste manier (bij back-ups in z'n algemeen, niet alleen Lightroom) is om back-ups met enige regelmaat te testen. Dat kan op verschillende manieren:
TEST 1: Lightroom Back-up catalogus openen met Lightroom:
Een heel eenvoudige manier om een back-up catalogus te testen is om er af en toe een te openen om te zien wat er gebeurt.
Omdat de gebackupte Lighroom catalogi tegenwoordig ingepakt zijn (in het zip formaat) moet je die dan wel eerst uitpakken (In Windows gewoon rechtsklikken en ‘Alles uitpakken…’ kiezen:
De uitgepakte .LRCAT file kun je het eenvoudigste openen door erop te dubbelklikken. Lightroom start dan op met deze catalogus. In dit geval blijkt al meteen dat de back-up blijkbaar corrupt is:
Lightroom sluit vervolgens af en wanneer je hem weer probeert te openen zie je onderstaande dialoogscherm. De optie ‘Catalogus herstellen’ is hoopgevend…
Toch blijkt dat er echt niets meer aan te doen is:
Je zult in dit geval moeten uitwijken naar een andere (eerdere) back-up. In dit geval is het maar een test en ben ik dus niet echt afhankelijk van deze back-up, gelukkig maar.
TEST 2: Database onderzoeken
Een alternatieve manier waarbij je de catalogus echt aan een nader (technisch) onderzoek onderwerpt is met tooling die de onderliggende SQLite database analyseert. Daarbij twee opmerkingen:
1. Hiermee kunnen fouten worden ontdekt die Lightroom zelf heeft gemist bij zijn integriteitstest. Een catalogus waar Lightroom geen problemen ziet kan dus toch corruptie bevatten.
2. Andersom zal deze test de Lightroomspecifieke testen (die Lightroom zelf uitvoert) niet doen. Het kan dus zijn dat Lightroom zelf fouten ontdekt die niet naar voren komen bij deze integriteitscontrole op databaseniveau.
Met andere woorden: beide testen moeten succesvol zijn. Wanneer één van beide faalt dan heb je een probleem.
Stap 1.
Download “SQLite Expert Personal” en installeer deze: Directe downloadlink: http://www.sqliteexpert.com/v5/SQLiteExpertPersSetup64.exe
Stap2.
Stap2.
Start het programma en kies in het menu “File” en daarna “Open database”. Navigeer naar het .lrcat bestand dat je wilt controleren. Die zie je overigens alleen wanneer je de optie “All files” selecteert in het dialoogscherm:
Stap3.
Stap3.
Klik nu op de “Check” knop onder in het scherm, dan volgt het resultaat vrij snel:
In dit geval is er dus blijkbaar een probleem. De melding op zich zegt me niet zo veel maar alleen al deze melding toont aan dat het om een corrupte database gaat die je niet meer kunt gebruiken.
Stap 4.
In dit geval is er dus blijkbaar een probleem. De melding op zich zegt me niet zo veel maar alleen al deze melding toont aan dat het om een corrupte database gaat die je niet meer kunt gebruiken.
Stap 4.
Wanneer ik een andere catalogus test waarvan ik het vermoeden heb dat die wel goed is krijg ik een daarvan meteen een bevestiging:
Stap 4.
Dit kun je periodiek herhalen voor de catalogie die je wilt testen.
Nog enkele waarschuwingen:
·
Nog enkele waarschuwingen:
- Check alleen uitgepakte catalogi; pak zipbestanden dus eerst uit
- Overschrijf de catalogus (of catalogi) waarmee je werkt niet per ongeluk door een versie uit een back-up!
- Maak niet allen back-ups maar controleer ze van tijd tot tijd ook eens
·
Posts
Geen opmerkingen:
Een reactie posten