LR Backup dauert lange; was genau macht LR da?

[Andy_Piano]

Hey Leute,

ich habe das interne Katalog-Backup in Lightroom aktiviert und werde bei jedem Beenden gefragt, ob ich ein Backup machen möchte.
Mein Katalog ist aktuell genau 947 MB groß. Er liegt auf einer internen SSD, das Backup wird auf meinem NAS gespeichert.

Mir ist schon länger aufgefallen, dass das Backup ziemlich lange dauert, mir aber nichts dabei gedacht. Nun habe ich mal einen Test gemacht:

Das Backup, von Lightroom erstellt, dauerte eben genau 4:35 min! Davon sind 8 Sek. die Prüfung der Integrität vor der Sicherung und ca. 15 Sekunden Optimierung des Katalogs nach der Sicherung. Bleiben gute 4:10 min netto für das reine Backup.
Also es wird nur der Katalog gesichert, die Vorgaben werden nicht mit dem Katalog gespeichert. Der Backup-Ordner enthält demnach wirklich nur die reine .lrcat-Datei.

Mache ich das Backup manuell über den Windows Explorer, also kopiere ich einfach die .lrcat-Datei auf das NAS dauert das nur 10 Sekunden.

Woher kommt dieser extrem krasse Zeitunterschied? Sieht man von der Integritätsprüfung und der Optimierung (die ziemlich schnell gehen) ab, macht LR doch das gleiche: den Katalog auf das NAS kopieren.
Oder verstehe ich da was falsch und LR macht doch mehr?
Ansonsten würde ich dazu übergehen, das Backup immer manuell machen, denn 4:30 min für das Backup sind mir im Gegensatz zu 10 Sek. doch etwas zu lang ...

 

[GymfanDE]

Da ich kein LR nutze, bleibt nur die Ferndiagnose: legt LR wirklich ein Backup per Kopie des Datenbankfiles an? Oder erzeugt es am Ziel vieleicht eine neue Datenbank und schreibt die Daten dann dort hinein?

Falls Adobe den (korrekten) offiziellen Weg geht, dann machen sie genau dies:
http://stackoverflow.com/questions/25675314/how-to-backup-sqlite-database
oder in der längeren Erklärung:
https://www.sqlite.org/backup.html

Das ganze müsste sich mittels Task Manager ermitteln lassen (CPU-Auslastung von LR und vom System).

Ansonsten würde ich dazu übergehen, das Backup immer manuell machen,

Hoffentlich erst dann, wenn LR garantiert geschlossen ist. Nicht, dsss LR das SQLite DB-File immer offen hat und Du ansonsten eine u.U. inkonsistente Datenbankkopie hast.

 

[Rudolino]

Hallo Panke,
bei mir dauert das komplette LR-Katalogbackup auf eine normale HD 28 sec. Der Katalog ist 149MB groß.
Wenn man das auf Deine Kataloggröße mit 947MB hochrechnet, komme ich auf 3,2 Minuten. Da wir unterschiedliche Rechner besitzen, kann der von Dir gemessene Wert völlig OK sein.

 

[NaumannU]

Was läuft da als NAS und wie ist das angebunden?

 

[Rudolino]

Nachtrag:
Ich vermute, die SQLite Datenbank wird mit SQLite Bordmitteln gesichert, z.B. mit der SQLite Backup Api. Damit wird meines Erachtens nach sichergestellt, dass eine konsistente und optimierte Sicherungsdatenbank vorliegt. Die Abarbeitung der Scriptbefehle dauert halt um einiges länger als das reine Kopieren der Datenbankdatei im Windows-Explorer.
Wenn man regelmäßig die Prüfung/Optimierung des Katalogs durchführt, spricht eigentlich nichts dagegen, eine andere schnellere Backup- oder Synchronisierungssoftware zu benutzen. Oder sehen das die Experten anders?

Seit einiger Zeit sichere ich alle Lightroom Bilderordner/Bilder und Katalogordner nebst allen Vorschaubildern auf USB-Platten. Dies hat den schönen Nebeneffekt, dass ich eine USB-Platte mit einem Dublikat nur an einen anderen Rechner mit LR anschließen muss, um meine gewohnte Umgebung zu haben.

 

[Gast_129296]

Wenn man regelmäßig die Prüfung/Optimierung des Katalogs durchführt, spricht eigentlich nichts dagegen, eine andere schnellere Backup- oder Synchronisierungssoftware zu benutzen. Oder sehen das die Experten anders?

Die SQLLite Entwickler hane das API ja nicht ganz ohne Grund entwickelt, das funzt auf jedem OS und beachtet alles, was wichtig ist, damit man mit der Sicherung auch was anfangen kann.

Alle Datenbanksysteme bieten ähnliche Mechanismen, die völlig unabhängig vom OS eine Sicherung ermöglichen.

Man kann eine eigene Prozedur stricken, die sicherstellt, das der Check in LR gelaufen ist und nur dann auch gesichert wird, und dabei überwacht wird, das keiner auf die Datei zugreift etc - aber will man das ?

Evtl nochmal eine Sicherung auf die lokale Platte versuchen, aber hier liegt die Laufzeit im vergleichbaren Bereich 3-4min ( auf lokale Platte, 980 GB Katalog )

 

[GymfanDE]

Man kann eine eigene Prozedur stricken, die sicherstellt, das der Check in LR gelaufen ist und nur dann auch gesichert wird, und dabei überwacht wird, das keiner auf die Datei zugreift etc - aber will man das ?

Die Frage wäre bei mir eher, ob ich bei jedem Beenden von LR eine Sicherung benötige (oder ob LR die benötigt, ich hoffe doch nicht).

Wenn nicht, dann würde ich einfach einen Windows-Task einrichten, der entweder nachts (falls LR nicht läuft) oder beim Runterfahren des Systems das LR-DB File auf das NAS kopiert. Dank SQLite ist das nun wirklich kein Problem. Dies ist einer der ganz wenigen Vorteile von SQLite gegenüber einer vernünftigen Datenbank, den LR hoffentlich nicht durch eine falsche Verwaltung der DB zu Nichte macht.

Evtl nochmal eine Sicherung auf die lokale Platte versuchen, aber hier liegt die Laufzeit im vergleichbaren Bereich 3-4min ( auf lokale Platte, 980 GB Katalog )

Das sollte wohl eher 980 MB heissen, oder? 4 GB/Sekunde Kopiergeschwindigkeit wäre schon eine verdammt gute Leistung.

 

[Manni1]

Ich hab noch nie mit LR-Mitteln eine Sicherung gemacht, das Betriebssystem selbst hat dafür ausreichend Mittel. XCOPY zum Beispiel.

 

[Gast_129296]

Die Frage wäre bei mir eher, ob ich bei jedem Beenden von LR eine Sicherung benötige (oder ob LR die benötigt, ich hoffe doch nicht).

Ich entscheide das nach der Menge der Änderungen, wenn ich viel entwickle, sichere ich, wenn nicht überspringe ich. Ich finde die paar Minuten allerdings nicht besonders dramatisch.

Ich hab noch nie mit LR-Mitteln eine Sicherung gemacht, das Betriebssystem selbst hat dafür ausreichend Mittel. XCOPY zum Beispiel.

Kann man machen, Vorteil der LR Prozedur, die DB wird vor der Sicherung auf Integrität geprüft. Sichere ich DB unabhängig, dann muss ich sicherstellen, das in LR zu tun. Und ich muss sicherstellen, das LR nicht läuft.

Ist eine Frage dessen, was man erreichen möchte.

Das sollte wohl eher 980 MB heissen, oder? 4 GB/Sekunde Kopiergeschwindigkeit wäre schon eine verdammt gute Leistung.

Ja, vertippt.

Dies ist einer der ganz wenigen Vorteile von SQLite gegenüber einer vernünftigen Datenbank, den LR hoffentlich nicht durch eine falsche Verwaltung der DB zu Nichte macht.
.

Jedes DB System lässt sich problemlos sichern, wenn es offline ist und die DB geschlossen ist. Das ist keine SQLite Besonderheit.

 

[Andy_Piano]

Moin Leute,

erstmal danke für die Antworten.

legt LR wirklich ein Backup per Kopie des Datenbankfiles an? Oder erzeugt es am Ziel vieleicht eine neue Datenbank und schreibt die Daten dann dort hinein?
Das ganze müsste sich mittels Task Manager ermitteln lassen (CPU-Auslastung von LR und vom System).

Gute Frage. Darüber habe ich noch gar nicht nachgedacht. Müsste ich später zuhause mal darauf achten.

Hoffentlich erst dann, wenn LR garantiert geschlossen ist. Nicht, dsss LR das SQLite DB-File immer offen hat und Du ansonsten eine u.U. inkonsistente Datenbankkopie hast.

Aber natürlich.

Was läuft da als NAS und wie ist das angebunden?

Synology DS214 über Gigabit. Schreibraten von über 100 MB/s sind kein Problem. Daher dauert ja auch das manuelle Backup von knapp 1 GB nur 10 Sek.

Ich vermute, die SQLite Datenbank wird mit SQLite Bordmitteln gesichert, z.B. mit der SQLite Backup Api. Damit wird meines Erachtens nach sichergestellt, dass eine konsistente und optimierte Sicherungsdatenbank vorliegt. Die Abarbeitung der Scriptbefehle dauert halt um einiges länger als das reine Kopieren der Datenbankdatei im Windows-Explorer.

Die SQLLite Entwickler hane das API ja nicht ganz ohne Grund entwickelt, das funzt auf jedem OS und beachtet alles, was wichtig ist, damit man mit der Sicherung auch was anfangen kann.
Alle Datenbanksysteme bieten ähnliche Mechanismen, die völlig unabhängig vom OS eine Sicherung ermöglichen.

Das wäre auf jeden Fall ein plausible und akzeptable Erklärung.

Die Frage wäre bei mir eher, ob ich bei jedem Beenden von LR eine Sicherung benötige (oder ob LR die benötigt, ich hoffe doch nicht).

Nein, das nicht. Und ich mache das auch nicht immer. Aber ich lasse die Nachfrage bewusst immer kommen, damit ich immer daran erinnert werde.

Wenn nicht, dann würde ich einfach einen Windows-Task einrichten, der entweder nachts (falls LR nicht läuft) oder beim Runterfahren des Systems das LR-DB File auf das NAS kopiert. Dank SQLite ist das nun wirklich kein Problem. Dies ist einer der ganz wenigen Vorteile von SQLite gegenüber einer vernünftigen Datenbank, den LR hoffentlich nicht durch eine falsche Verwaltung der DB zu Nichte macht.

Das wäre ja im Grunde das gleiche wie die .lrcat-Datei einfach über den Windows Explorer zu kopieren, oder sehe ich das falsch?

Ich finde die paar Minuten allerdings nicht besonders dramatisch.

Nein, das sind sie nicht. Und wenn es vorteilhaft/sicherer ist, das LR-Backup zu nutzen, dann nehme ich die paar Minuten auch in Kauf. Mich hat eben einfach nur interessiert, woher dieser Zeitunterschied kommt ...

 

[wysiwyget]

Du kannst genau so eine 1:1 Kopie mit dem OS des lrcat files machen.

Ist die Performance des Backup auf die SSD (würde ich mal testweise machen) genau so langsam?

 

[Manni1]

Vorteil der LR Prozedur, die DB wird vor der Sicherung auf Integrität geprüft.

Und was ist, wenn da ein Problem erkannt wird, der Katalog also irgendwie fehlerhaft ist? Versucht Lightroom da eine Reparatur? Falls sowas Erfolg hat, sollte das auch mit der DB eines Backups möglich sein.

Da meine OS-basierten Sicherungen auf unterschiedlichen Medien erfolgen, kann ich auch bei später erkannten Fehlern noch auf eine ältere Version des Katalogs zurückgreifen, in dem halt die letzten Arbeiten fehlen.

 

[Gast_129296]

Versucht Lightroom da eine Reparatur? Falls sowas Erfolg hat, sollte das auch mit der DB eines Backups möglich sein.

Ob eine Reperatur möglich und erfolgreich ist, wird immer vom Problem abhängen.

Indem man in SQLite einen kompletten Prozess abbildet ( Integritätsstest - Sicherung - Prüfung ) merkt man im Moment des ersten Problems, das man eins hat.

Wenn Du "nur" mit OS Mitteln sicherst, und dann nicht regelmässig den Katalog in LR prüfst, stellst Du evtl sehr spät fest, das Du ein Problem hast.

Beide Szenarien können ok sein, das ist abhängig von den Anforderungen.

Nur müsstest Du bei 2 zurückgehen in den Sicherungen und den letzten "reperablen" oder intakten Katalog finden. Das kann dann schon zu Problemen / Verlust führen.

Und das wichtigste am Backup ist ja, das der Restore auch klappt.

Und was ist, wenn da ein Problem erkannt wird, der Katalog also irgendwie fehlerhaft ist? Versucht Lightroom da eine Reparatur? Falls sowas Erfolg hat, sollte das auch mit der DB eines Backups möglich sein.

Kann er, ist aber eben nicht "genauso". s.o..

 

[GymfanDE]

Das wäre ja im Grunde das gleiche wie die .lrcat-Datei einfach über den Windows Explorer zu kopieren, oder sehe ich das falsch?

Es ist das gleiche, so lange Du vor dem Kopieren (wie Du ja schreibst) LR beendet hast, Dir zu 100% sicher bist, dass der LR-Prozess beendet ist und LR auch nichts mehr im Hintergrund macht. Mit dem Script könnte man sowas zusätzlich prüfen (wenn das bei LR nötig sein sollte).

Der einzige, für mich aber entscheidende Unterschied ist der Automatismus. Ich müsste mich weder bei jedem Schliessen von LR entscheiden, was ich machen will, noch muss ich zum Kopieren irgendwas manuell anstoßen. Da ich meinen PC jeden Abend runter fahre, sichere ich auf dieser Weise die SQLite-Datenbank meiner Bildverwatung automatisch.

 

[Gast_129296]

Es ist das gleiche, so lange Du vor dem Kopieren (wie Du ja schreibst) LR beendet hast, Dir zu 100% sicher bist, dass der LR-Prozess beendet ist und LR auch nichts mehr im Hintergrund macht.

Was fehlen würde wäre die Integriätsprüfung.