Olympus Workspace - Datensicherung / Portierung auf anderen Rechner

[Erich_Wien]

Ist auch anderen schon aufgefallen, dass OWS eigentlich keine Datensicherung hat, die den Namen auch verdient?
Ich meine damit nicht die RAW-Files zu sichern, sondern alle Bearbeitungsschritte welche man in OWS vornimmt.
Es gibt war eine SQLite-Datenbank in der alles vorhanden ist, aber diese nützt einem nichts, da zu jeder Datei welche importiert wurde, ein eigener Key für das Laufwerk zugeordnet wird (Feld "disk_vsn")
Portiert man nun die komplette Datenbank auf einen anderen Rechner und stellt die RAW-Files in die exakt selbe Dateistruktur, sind dennoch alle Anpassungen verloren gegangen.
Man hat dann zwei Einträge je RAW-File in der Tabelle "file_table" mit den exakt selben Daten - aber der Ausnahme des Feldes "disk_vsn" (Seriennummer der Platte - nehme ich an).
Und sämtliche Bearbeitungen sind mit der ID des ursprünglichen Eintrags und dessen "disk_vsn" verknüpft.

Der einzige Umweg ist, in OWS direkt mittels "kopieren" die komplette Struktur auf ein Laufwerk zu bringen, denn damit werden sowohl die Files kopiert - als auch die DB-Einträge dupliziert.
Danach dann man die Datenbank auf den anderen Rechner kopieren (muss man auch erst mal finden) und nun von dem (z.Bsp. USB)-Laufwerk wieder zurückkopieren.
Dabei muss aber darauf geachtet werden, dass dem (USB)-Device der selbe Laufwerksbuchstabe zugeordnet wird, ansonsten hat man wieder "neue / unbearbeitete" Versionen.
Dann passt zwar die "disk_vsn" zusammen, aber der Path mit Laufwerksbuchstaben ist anders.

Das blöde bei der ganzen Sache ist nämlich, dass im Falles eines Festplattenausfalls man gar nicht mehr in der Lage ist, diesen "Kopier-Umweg" nachträglich zu gehen.
Denn die neue Platte hat eben bereits einen anderen Disk-Key ...
Man hat zwar eine Sicherung der Datenbank und eine Sicherung der RAW-Files, und dennoch sind alle Bearbeitungsschritte verloren gegangen.

Hier fehlt meines Erachtens einfach ein Export/Import-Tool für die DB-Einträge, welches die spezielle Disk-Kennung außer Acht lässt.

Ich würde mir wünschen, dass ich Blödsinn schreibe und einfach etwas übersehen hab!?

 

[kdww]

Da lobe ich mir LR, KAtalog sichern, Bilder sichern,

Bilder auf neue Platte, wenn die den gleiche Buchstaben hat wie vorher und der Rootordner nicht geändert wurden, gibt es, ausser den Katalog von einem Beliebigen Verzeichnis zu starten, nichts zu tun.

Ich hatte beim neuen Rechern LR installiert, den Katalog rüberkopiert und gestartet, parallel lief dazu die Rücksicherung der Bilder, da konnte man in LR zuschaen, wie im Verzeichis die Ausrufezeichen verschwanden.

Ich habe immer mal wieder WS probiert, aber das ging über meine persönliche Leidensfähigkeit hinaus.

[Grek-1]

@kdww Deine Aussage hilft dem TO nicht wirklich weiter.

Warum nimmst du nicht ein einfaches Backup-Programm dafür, Erich? Da kannst du gleich auch deinen kompletten Rechner sichern.

bearbeitet 15. Mai 2023 von Grek-1

[Erich_Wien]

vor 21 Minuten schrieb Grek-1:

@kdww Deine Aussage hilft dem TO nicht wirklich weiter.

Warum nimmst du nicht ein einfaches Backup-Programm dafür, Erich? Da kannst du gleich auch deinen kompletten Rechner sichern.

Das ist ja das eigentliche Problem, Rolf!
In dem Backup welches die WS-Datenbank beinhaltet, stehen die Kennungen der alten Platte.
Spielt man das nach einem Ausfall auf eine neue Platte zurück (welche eine neue Seriennummer hat), sind die Beziehungen zwischen den RAW-Files und den DB-Einträgen verloren.

[-noel-]

Das ist ja echt bescheuert! Wenn man sich ein bisschen auskennt könnte man mit einem SQL Editor evtl. das Feld "disk_vsn" auf den neuen Wert der neuen Platte umbiegen, aber das ist wirklich nur was für Leute die sich damit auskennen. Gibts nicht irgendwo eine "Bug-Page" im WWW, wo man OMDS bzw. den Entwicklern diesen Fehler kundtun kann?

Grüße
Ebe

[kdww]

vor 1 Stunde schrieb Grek-1:

@kdww Deine Aussage hilft dem TO nicht wirklich weiter.

Das war der dezente Hinweis ein vernünftiges Programm zu nutzen 🙂

Und es hilft anderen hier nicht aufs falsche Pferd zu setzen.

Es wäre mir ein Graus, eine Datensicherung zu haben, bei der mich die verwendete Software beim Recovery im Regen stehen lässt und ich alle Bearbeitungen verliere. 
Für mich gehört zur Auswahl eines Programms auch die Sicherheit der Daten und die ist wohl hier überhaupt nicht gegeben. Da kann man sich die Datensicherung der Datenbank praktisch sparen. 

vor 8 Minuten schrieb -noel-:

Gibts nicht irgendwo eine "Bug-Page" im WWW, wo man OMDS bzw. den Entwicklern diesen Fehler kundtun kann?

Nein. 

Stimmt nicht ganz:

 

bearbeitet 15. Mai 2023 von kdww

[Erich_Wien]

vor 12 Minuten schrieb -noel-:

Wenn man sich ein bisschen auskennt könnte man mit einem SQL Editor evtl. das Feld "disk_vsn" auf den neuen Wert der neuen Platte umbiegen, aber das ist wirklich nur was für Leute die sich damit auskennen.

Hab ich ehrlich gesagt eh gleich versucht 🙂
Aber das Feld "disk_vsn" dient scheinbar zusätzlich zur Berechnung eines Hash-Wertes welcher dann den Pfadangaben noch angehängt wird.
Damit wirds immer mühsamer ...
 

[Erich_Wien]

vor 16 Minuten schrieb kdww:

Es wäre mir ein Graus, eine Datensicherung zu haben, bei der mich die verwendete Software beim Recovery im Regen stehen lässt und ich alle Bearbeitungen verliere.
Für mich gehört zur Auswahl eines Programms auch die Sicherheit der Daten und die ist wohl hier überhaupt nicht gegeben. Da kann man sich die Datensicherung der Datenbank praktisch sparen. 

Bin ich voll und ganz bei Dir!
Ich hab aber das Gefühl, dass das eigentlich kaum jmand weiß, wie mühsam die Vorgehensweise ist - bevor es einen trifft.
Oder besser gesagt, dass man sich mit einem Backup in falscher Sicherheit wiegt.
Daher auch meine Hoffnung dass ich komplett falsch liege und bloß etwas übersehen habe. Aber diese schwindet immer mehr .... ^^

[kdww]

Daher ist es auch gut, dass du das Thema hier adressierst.

Ich drück dir die Daumen, dass es irgendwie noch ohne Verluste geht.

Kann man die Bearbeitungen in XMP Dateien exportieren, die man dann neu einliest wenn man das Bild bearbeitet?
Das ist bei LR auch immer ein Notnagel, wenn alles andere versagen sollte.

[Erich_Wien]

vor 7 Minuten schrieb kdww:

Kann man die Bearbeitungen in XMP Dateien exportieren, die man dann neu einliest wenn man das Bild bearbeitet?

Leider nein.

Das wäre genau die wünschenswerte Art, Portabilität zu gewährleisten.
Einfach ein neutrales (direkt lesbares) Export-Format welches einen HW-unabhängigen Verweis auf das Raw-File und alle Bearbeitungsschritte beinhaltet.
Und das möglichst für die ganze Kollektionen, nicht nur für einzelne Fotos, sonst wirds auch langweilig 🙂

[Fioshrek]

Einfach nur ein Denkansatz: alles in eine virtuelle Festplatte hineinstopfen - im Endeffekt eine Datei die gut gesichert werden kann und die Kennung der "Festplatte" wird sich nicht mehr ändern.

[Erich_Wien]

vor 5 Minuten schrieb Fioshrek:

Einfach nur ein Denkansatz: alles in eine virtuelle Festplatte hineinstopfen - im Endeffekt eine Datei die gut gesichert werden kann und die Kennung der "Festplatte" wird sich nicht mehr ändern.

Das klingt wirklich nach einem sehr guten Ansatz!
Man müsste bei neu aufsetzen halt den selben Laufwerksbuchstaben zuordnen - dann müsste wirklich alles ident sein.
Wenn man dieses Virt.-Drive auch noch als als Installationsziel für OWS verwendet, hat man auch die DB mit dabei.

Sehr clever!

[Grinzold]

Am 15.5.2023 um 08:28 schrieb Erich_Wien:

Hab ich ehrlich gesagt eh gleich versucht 🙂
Aber das Feld "disk_vsn" dient scheinbar zusätzlich zur Berechnung eines Hash-Wertes welcher dann den Pfadangaben noch angehängt wird.
Damit wirds immer mühsamer ...
 

Erich, das ist kein Hash, sondern die Hex-Darstellung der dezimalen Platten-ID.

[Erich_Wien]

vor 6 Minuten schrieb Grinzold:

Erich, das ist kein Hash, sondern die Hex-Darstellung der dezimalen Platten-ID.

 

Du bist ja ein Knüller!!!
Da wäre mir nie in den Sinn gekommen.
Bist du nicht bei den Fotorätseln auch immer ganz vorne dabei? ^^

[Grinzold]

vor 13 Minuten schrieb Erich_Wien:

Bist du nicht bei den Fotorätseln auch immer ganz vorne dabei? ^^

Beim Daneben-Tippen? Klar!!🤪🤪

Jetzt schieße ich verm. übers Ziel hinaus, aber die ID riecht nach einer UNIX-Timestamp... "24.08.2012"... Scheint mir jetzt etwas zu alt.

[Erich_Wien]

vor 15 Stunden schrieb Grinzold:

Jetzt schieße ich verm. übers Ziel hinaus, aber die ID riecht nach einer UNIX-Timestamp... "24.08.2012"... Scheint mir jetzt etwas zu alt.

Wird eher Zufall sein. Die genannte ID stammt schon von der neuen Platte. Ich denke diese 1TB-SSD gab es 2012 noch nicht.
Außer man hat mir wirklich alten Mist angedreht ^^

[Grinzold]

vor 21 Minuten schrieb Erich_Wien:

Außer man hat mir wirklich alten Mist angedreht ^^

Am Ende kommt alles raus... 😈🤣

[Erich_Wien]

vor 22 Minuten schrieb Grinzold:

Am Ende kommt alles raus... 😈🤣

Stell mir grad den Dialog vor ...

Sie haben mir eine uralte Platte eingebaut!!!
Woher wissen Sie das?
Ich hab Olympus Workspace installiert!

😀

[pit-photography]

vor 57 Minuten schrieb Erich_Wien:

Wird eher Zufall sein. Die genannte ID stammt schon von der neuen Platte. Ich denke diese 1TB-SSD gab es 2012 noch nicht.

Vielleicht war das ein Prototyp 😄

[Erich_Wien]

vor 30 Minuten schrieb pit-photography:

Vielleicht war das ein Prototyp 😄

Daher die Bauhöhe einer Sachertorte und das seltsame summen .... ^^

[Grinzold]

vor 6 Minuten schrieb Erich_Wien:

und das seltsame summen ....

Das ist der integrierte Trafo. 🔌⚡

[kdww]

Am 15.5.2023 um 10:28 schrieb Fioshrek:

Einfach nur ein Denkansatz: alles in eine virtuelle Festplatte hineinstopfen - im Endeffekt eine Datei die gut gesichert werden kann und die Kennung der "Festplatte" wird sich nicht mehr ändern.

 

Am 15.5.2023 um 10:37 schrieb Erich_Wien:

Das klingt wirklich nach einem sehr guten Ansatz!
Man müsste bei neu aufsetzen halt den selben Laufwerksbuchstaben zuordnen - dann müsste wirklich alles ident sein.
Wenn man dieses Virt.-Drive auch noch als als Installationsziel für OWS verwendet, hat man auch die DB mit dabei.

Ich habe mir das mal überlegt, weil mich die Idee für was anderes interessiert.

Ich sehe da ein paar Dinge, die zu bedenken sind, damit man nicht vom Regen in die Traufe kommt

1.
Die Installation des WS in das virtuelle Drive, wenn sie klappt, nützt nicht viel, weil dir am Ende die Registry einträge fehlen und viele Programme sind Zickig, wenn sie nicht im Standard Pfad installiert werden.

2.
Backup, ja ist nur eine Datei, ich habe mit meinen bescheidenen 26.000 Fotos in 15 Jahren bei Kameras mit max. 20 Megapixel immerhin rund 500 GByte Daten zusammengebracht.
Ich mache ein Differenzbackup, sichere also nur was sich geändert hat, die die 500GByte möchte ich nicht jedes mal beim Backup am Stück sichern müssen.
Eventuell kann man hier auch die Einzeldateien sichern und dann hin und wieder die Gesamtdatei sichern. Sowas ist aber kompliziert und fehlerträchtig und wiederspricht meinem Anspruch an eine simple Backupstrategie.

[Erich_Wien]

vor 5 Stunden schrieb kdww:

Die Installation des WS in das virtuelle Drive, wenn sie klappt, nützt nicht viel, weil dir am Ende die Registry einträge fehlen und viele Programme sind Zickig, wenn sie nicht im Standard Pfad installiert werden.

Man müsste herausfinden, ob im Zuge der Installation von OWS, bestehende DB-Files überschrieben werden.
Wenn dem nicht so ist, könnte man anschließend OWS erneut in dieses Ziel installieren, damit die Reg-Einträge passieren (ich hasse diese Registry!!!!!)

 

vor 5 Stunden schrieb kdww:

Backup, ja ist nur eine Datei, ich habe mit meinen bescheidenen 26.000 Fotos in 15 Jahren bei Kameras mit max. 20 Megapixel immerhin rund 500 GByte Daten zusammengebracht.

Ich mache ein Differenzbackup, sichere also nur was sich geändert hat, die die 500GByte möchte ich nicht jedes mal beim Backup am Stück sichern müssen.
Eventuell kann man hier auch die Einzeldateien sichern und dann hin und wieder die Gesamtdatei sichern. Sowas ist aber kompliziert und fehlerträchtig und wiederspricht meinem Anspruch an eine simple Backupstrategie.

Absolut legitime Bedenken!
Ich muss gesehen, dass ich mich mit den Backup-Methoden unter Windows nicht auskenne.
Aber unter Linux verwende ich stets "rsync" - welches auf dem Quell- und Zielsystem die zu synchronisierenden Daten nur liest und dabei Hashes abgleicht.
Geschrieben wird nur, wenn es Abweichungen gibt.
Damit ist man auch bei gewaltigem Datenvolumen unglaublich flott in der Synchronisation.
Ich kann mir gut vorstellen, dass es ähnliche oder noch effizientere Methoden unter Windows gibt.
 

[kdww]

Ich habe das unter Windows mit Xcopy (gesetztes Archivbit= es hat sich was geändert) gemacht, mittlerweile bin ich auf Robocopy umgestiegen, aber gleiches Kriterium.

[koimann]

Es gibt hier schon einen Thread der dazu passt: Migration von Workspace auf neuen PC
vielleicht hilft das ja.