Diverse Bug-Reports zu DiskImage 12 v129

Professional / Workstation / Server Edition
Antworten
cookie
Beiträge: 7
Registriert: Mi 28. Feb 2018, 21:42

Diverse Bug-Reports zu DiskImage 12 v129

Beitrag von cookie » Mi 28. Feb 2018, 21:50

Ich setze seit nunmehr fast einem Jahrzehnt für mein Backup O&O DiskImage ein. Im Schnitt bin ich bei jeder zweiten Version dabei. Ich hatte bislang sehr gute Erfahrungen damit.

Nachdem derzeit ein sehr günstiges Angebot läuft um mich und meine Familie auf den aktuellen Stand zu bringen habe ich mir Version 12 angesehen. Sie hat bei mir einen sehr flauen Eindruck hinterlassen.

Bei meinem Vorab-Test von Version 12 habe ich folgende reproduzierbare Fehler gefunden:
1. Trivial: Warum verlinkt Ihr eigentlich für den Demo-Download noch die alte .118-Version obwohl .129 schon Ende Januar herauskam? Zumal der Auto-Updater wohl bei einigen (und mir) manchmal fehlschlägt. Auch bei mir ging das nicht auf Anhieb sondern erst irgendwann. Leider ohne Details. Meine Fehler konnte ich aber alle auch in .129 nachstellen.
2. Ich finde es toll dass Version 12 seine CLI-Schnittstelle ausgebaut hat. Aber beim image erstellen ist scheinbar das exclude fehlerhaft. Exkludiere ich einen Ordner mit /exclude "ordner", gibt es ihn wirklich optisch danach im Backup nicht mehr. Die Erstellung des Backups dauert aber genauso lange wie ohne exclude und das Backup ist auch plusminus ein paar Byte genauso groß wie das ohne Exklusion. Der exkludierte Ordner war riesig. Mit Exklusion war das Backup kaum mehr als Luft und hätte entsprechend klein sein müssen.

Ferner habe ich Fehler gefunden die für ein Backup-Programm extrem gruselig sind
Grundszenario: Ich habe mir einen USB-Stick mit nicht mehr benötigten Daten geschnappt, ein Backup gezogen und wollte ihn gleich wieder restoren.
Ich hatte folgende Festplatten-Konstellation:SSD1-SSD2-VHDX-Virtuelles Laufwerk (Vera/TrueCrypt) (in dieser Reihenfolge als Datenträger erkannt und nummeriert). Außerdem war eine externe Festplatte angeschlossen aber nicht eingeschaltet. Windows (8.1) hat diese als Geist-Laufwerk ohne Inhalt gesehen. So ähnlich wie ein SD-Kartenleser in den man noch nichts eingelegt hat.
3. Ich habe einen USB-Stick eingesteckt und die Laufwerksanzeige aktualisiert. Er hat sich dann in der Laufwerksnummerierung in DiskImage zwischen SSD2 und VHDX eingereiht. Wiederherstellung gestartet, Ziel: USB-Stick. Wie erwartet kam eine Abfrage ob ich den Datenträger wirklich überschreiben will. ABER: Die Angabe, welche Partitionen ich dabei löschen würde, war die, dass auf diesem Datenträger gar nichts drauf wäre. DiskImage hat mich also visuell den USB-Stick auswählen lassen, bei der Wiederherstellung aber die !externe Festplatte! ausgewählt. Böses Foul. Wenn hier jemand nicht ganz genau hinsieht kann das sehr böse enden. Hatte ich auch später bei der Reproduktion des nächsten Punktes noch einmal als ich das RAW-Laufwerk des Folgepunkts zur Reproduktion immer mal wieder formatiert habe. Es scheint also Situationen zu geben in denen ein F5-Refresh in DiskImage dazu führt dass die UI-Anzeige und die Realität auseinanderdriften. --> Gruselig: Beim Versuch einen Stick wiederherzustellen kann ich mir schnell einen anderen Datenträger schrotten.
4. Nachdem klar war dass der F5-Refresh problematisch war habe ich das Programm neu gestartet sodass der Stick von vornherein erkannt wurde. Jetzt war immerhin die Frage ob ich das Laufwerk löschen wollte plausibel befüllt. ABER: Jetzt frägt mich DiskImage in einer Endlosschleife ob ich den Stick wirklich löschen will. Es läuft ständig zwischen Festplatten lesen, Partitionen lesen und dann eben dieser Frage hin und her --> Gruselig: Ich habe ein Backup, habe aber keine Chance es wiederherzustellen.
5. Nachdem die Frageschleife ganz offensichtlich ohne Erfolgsaussicht blieb habe ich abgebrochen. Das Programm hat das brav als abgebrochen quittiert. Trotzdem hat es den Stick gelöscht und/oder so beschädigt dass er danach ein RAW-Dateisystem hatte.
(4) und (5) konnte ich beliebig oft reproduzieren und sehen auf den ersten Blick genauso aus wie viewtopic.php?f=27&t=4184.


Zum Abschluss noch eine Sache die *angeblich* gar kein Fehler sein soll: Netzwerkpfade.

Bei meinen Tests von Version 12 wollte ich auch testen ob sie mittlerweile damit zurechtkommt nachdem die bisherigen Versionen bei Wiederherstellungen von Netzwerkpfaden immer große Probleme hatten. Eben dass man (spätestens differenzielle) Sicherungen nicht mehr mounten konnte oder dass eine Wiederherstellung ohne sinnvolle Fehlermeldung scheiterte. DiskImage hat extra einen Credential-Manager für Netzwerkpfade, also ging ich bislang sehr wohl davon aus dass die Entwickler das im Auge hatten.

Wegen der Fehler oben war das nicht vernünftig testbar. Aber ich bin über viewtopic.php?f=27&t=4316 gestolpert. Dass man das dort einfach als Einschränkung abgebügelt hat, hat mich ziemlich sprachlos gemacht. Vor allem weil keinerlei Erklärung gegeben wird.

Wie ich es sehe möchte sich O&O DiskImage gerne an jeden vom Privatnutzer bis zum Unternehmen richten. Jede dieser Benutzergruppen wird früher oder später Netzwerkpfade haben und davon sehr wenig begeistert sein.

a) Privatnutzer
Die heutigen PCs haben zunehmend nur noch eine SSD und damit Speicherknappheit. Das wird oft genug mit einer Billig-NAS kompensiert werden die dann eben ein Netzwerkpfad ist.
Die bisherigen Versionen konnten darauf ein Backup ablegen, es aber ganz schnell nicht mehr wiederherstellen. Irgendwann kommt man schon darauf dass man das Backup irgendwie lokal ablegen muss. Wenn man dafür die Hardware zuhause hat. Wenn der Benutzer das Know-How und die Geduld hat das zu durchblicken. Ansonsten wird er mächtig sauer sein.

b) Unternehmen
Ich arbeite in einem großen IT-Unternehmen und war dort auch einige Zeit Administrator. Da gibt es eben Backup-Server (oder wenn es DiskImage so wollen würde eben notfalls einen Netzwerkpfad) und nachgeschaltet Bänder. Lokal ablegen? Schon damit hätte sich DiskImage als Backuplösung disqualifiziert. Ein ernstzunehmendes Backup wird ganz bestimmt nicht auf einer Platte im selben Server liegen nur um zusammen mit diesem unterzugehen. Ab einer bestimmten Größe wird auch ganz bestimmt niemand in den schwer gesicherten gekühlten Serverraum laufen um zu versuchen eine USB-Platte an einem Port anzuschließen der ohnehin versiegelt sein wird. Davon dass das Umkopieren von Netzwerk auf Platte die Downtime weiter vergrößern würde (und dafür keiner Verständnis hat!) wollen wir gar nicht reden.
In einer hinreichend professionellen Umgebung führt kein Weg ums Netzwerk herum.

c) Power-User
Ich habe eine ganz typische Familie: Jeder hat einen Computer, jeder hat wichtige Daten, aber kümmern und auskennen tut sich dann doch keiner. Es soll halt laufen.
Um das ein für alle Mal vernünftig zu lösen habe ich dafür eine zentrale NAS die dann ihrerseits nochmal quergesichert wird. Jeder hat eine Lizenz aus dem Familienpaket. Einfach nur noch kurz das Backup anstoßen wenn mal Zeit ist. Und wenn es am Ende ich selbst bin der das kurz anstößt.

Mit der Credential-Verwaltung in DiskImage funktioniert das grundsätzlich. Aber eben nur genau so lange bis es eine Wiederherstellung braucht. Dann musste ich bislang immer erst einmal eine sehr große externe Festplatte herauskramen, alle Teilbackups von der NAS ziehen und dann direkt an den Computer ran. Falls der denn überhaupt eine geeignet schnelle Datenschnittstelle hat. Ansonsten geht es weiter mit Merging des Backups auf eine Datei, wieder auf die NAS – und hoffen dass es dann geht (früher ging es immerhin in diesem "Eine Datei"-Fall noch). Mit den typischen Festplatten-Geschwindigkeiten zieht sich das dann ganz schnell einen Tag lang hin.

Mit einer Wiederherstellung von der NAS aus wäre das dramatisch einfacher.


Wenn die Entwickler offenbar der Meinung waren dass das kein Fehler sondern einfach ein Limit ist: Was würden dann die Entwickler
-dem Power-Nutzer sagen der tierisch genervt ist dass ein simples Restore durch hin und herkopieren eine Tagesaufgabe wird
-dem Privatnutzer sagen der sein Backup nicht wiederhergestellt bekommt weil er keine externe Festplatte und keinen zweiten Computer zum umkopieren hat,
-dem Unternehmen sagen das gar nichts anderes als einen Netzwerkpfad nutzen kann
?

cookie
Beiträge: 7
Registriert: Mi 28. Feb 2018, 21:42

Re: Diverse Bug-Reports zu DiskImage 12 v129

Beitrag von cookie » Do 8. Mär 2018, 22:21

<<Gelöscht weil sich doch noch jemand gemeldet hat>>
Zuletzt geändert von cookie am Sa 10. Mär 2018, 17:35, insgesamt 1-mal geändert.

Benutzeravatar
Alex (O&O)
Beiträge: 385
Registriert: Do 30. Jun 2011, 11:37

Re: Diverse Bug-Reports zu DiskImage 12 v129

Beitrag von Alex (O&O) » Fr 9. Mär 2018, 06:11

Hallo cookie,

Es tut mir leid, dass bisher noch niemand auf ihren Artikel eingegangen ist. Das Forum wird von uns nachrangig behandelt. Wenn Kunden Probleme haben, sollen sie sich primär an den Support wenden.
Zuerst vielen Dank, dass Sie sich die Zeit genommen haben, um sich das Produkt anzuschauen. Um Ihnen wirklich helfen zu können, benötigen wir leider noch ein paar Informationen sowie die Systeminfo von dem Rechner, auf dem Sie Ihre Tests durchgeführt haben und die zu den Testfällen gehörige Protokolldateien.

Zu Ihrem 2. Punkt:
Exkludiere ich einen Ordner mit /exclude "ordner", gibt es ihn wirklich optisch danach im Backup nicht mehr. Die Erstellung des Backups dauert aber genauso lange wie ohne exclude und das Backup ist auch plusminus ein paar Byte genauso groß wie das ohne Exklusion. Der exkludierte Ordner war riesig. Mit Exklusion war das Backup kaum mehr als Luft und hätte entsprechend klein sein müssen.
Welches Format der dateibasierten Sicherung oder welches Format der sektorenbasierte Sicherung haben sie gewählt ? Bei einer sektorenbasierten Sicherung werden die Datenbereiche der ausgeschlossenen Dateien nicht übernommen. Bei einer dateibasierten Sicherung werden die Dateien nicht in der Sicherungsdatei aufgenommen. Im ersten Fall wird die Sicherung nur viel kleiner, wenn die ausgeschlossenen Dateien entsprechend groß sind. Bei vielen kleinen Dateien, können die Daten der Dateien im Dateisystem selbst liegen.

Zu Ihrem 3. Punkt:
Wie erwartet kam eine Abfrage ob ich den Datenträger wirklich überschreiben will. ABER: Die Angabe, welche Partitionen ich dabei löschen würde, war die, dass auf diesem Datenträger gar nichts drauf wäre. DiskImage hat mich also visuell den USB-Stick auswählen lassen, bei der Wiederherstellung aber die !externe Festplatte! ausgewählt. Böses Foul. Wenn hier jemand nicht ganz genau hinsieht kann das sehr böse enden.
Unsere QA hat versucht das Verhalten zu reproduzieren, ohne Erfolg. Eine solcher Anzeigenfehler könnte in der Tat Probleme bereiten. Haben Sie evtl. Screenshots gemacht, damit wir das Problem eingrenzen können? Die Protokolldatei des Dienstes sowie der UI würden wir ebenfalls benötigen.

Zu Ihrem 4. Punkt:
ABER: Jetzt frägt mich DiskImage in einer Endlosschleife ob ich den Stick wirklich löschen will.
Können Sie uns bitte genauere Hardwareinformationen Ihres USB Sticks zukommen lassen.

Zu Ihrem 5. Punkt:
5. Nachdem die Frageschleife ganz offensichtlich ohne Erfolgsaussicht blieb habe ich abgebrochen. Das Programm hat das brav als abgebrochen quittiert. Trotzdem hat es den Stick gelöscht und/oder so beschädigt dass er danach ein RAW-Dateisystem hatte.
Das Programm kann keine Hardware beschädigen. In Falle eines Abbruchs werden auf allen Volumes, welche nicht vollständig wiederhergestellt/dupliziert werden konnten, die Bereiche der Bootsektoren mit 0 überschrieben. Das hat den Hintergrund, dass es zu Abstürzen von Dateisystemtreibern kommen kann, wenn ein defektes Dateisystem gefunden wurde. In solch einem Fall kann es zu einem BSOD kommen, was damit vermieden werden soll.

Zu Ihrem Abschluss:
Wegen der Fehler oben war das nicht vernünftig testbar. Aber ich bin über viewtopic.php?f=27&t=4316 gestolpert. Dass man das dort einfach als Einschränkung abgebügelt hat, hat mich ziemlich sprachlos gemacht. Vor allem weil keinerlei Erklärung gegeben wird.
Diese Aussage wird vom Support gegeben, um nicht jedes netzwerkfähige Laufwerk supporten zu müssen. Wir selber haben mehrere NAS Systeme für Homekunden zu testzwecken im Betrieb. Die meisten Kunden erwarten, dass alle Programme sofort mit jedem Netzwerklaufwerk erfolgreich arbeiten können. Da O&O DiskImage ein Dienst ist, welcher im Systemkontext laufen muss, kann dieser Dienst nicht im die Benutzerkontext angeschlossene Laufwerke „sehen“. Wir versuchen die in der UI ermittelten gemounteten Netzlaufwerke aufzulösen und die notwendigen Anmeldeinformation zu erfragen, um auf die Geräte zugreifen zu können.
Des Weiteren ist der Mounttreiber ein virtueller Gerätetreiber, welcher eine Disk simuliert. Wenn ein Gerät unter Windows nicht schnell genug antwortet, kann es passieren, dass Windows das Gerät abmeldet, da es von einem fehlerhaften Gerät ausgehen muss. Im schlimmsten Fall kann es zu einem BSOD kommen, wenn ein Dateisystem- oder ein Filtertreiber davon betroffen ist. Um Problem dieser Art zu vermeiden, wird die Aussage getroffen, die Sicherungsdateien lokal vorzuhalten.
Das gilt übrigens nur für die Mountfunktionalität. Eine Wiederherstellung, egal welcher Art und egal von welcher Sicherungsdatei, kann ohne Probleme von externen oder Netzlaufwerken durchgeführt werden!
Alex (O&O)

cookie
Beiträge: 7
Registriert: Mi 28. Feb 2018, 21:42

Re: Diverse Bug-Reports zu DiskImage 12 v129

Beitrag von cookie » Sa 10. Mär 2018, 17:42

Danke für die lange und ausführliche Antwort.

Ich werde wo möglich weitere Details liefern. Weil sich das in Umfang und Dauer etwas hinziehen kann teile ich das mal in mehrere Posts auf.
Zu Ihrem 4. Punkt:
ABER: Jetzt frägt mich DiskImage in einer Endlosschleife ob ich den Stick wirklich löschen will.
Können Sie uns bitte genauere Hardwareinformationen Ihres USB Sticks zukommen lassen.

Zu Ihrem 5. Punkt:
5. Nachdem die Frageschleife ganz offensichtlich ohne Erfolgsaussicht blieb habe ich abgebrochen. Das Programm hat das brav als abgebrochen quittiert. Trotzdem hat es den Stick gelöscht und/oder so beschädigt dass er danach ein RAW-Dateisystem hatte.
Das Programm kann keine Hardware beschädigen. In Falle eines Abbruchs werden auf allen Volumes, welche nicht vollständig wiederhergestellt/dupliziert werden konnten, die Bereiche der Bootsektoren mit 0 überschrieben. Das hat den Hintergrund, dass es zu Abstürzen von Dateisystemtreibern kommen kann, wenn ein defektes Dateisystem gefunden wurde. In solch einem Fall kann es zu einem BSOD kommen, was damit vermieden werden soll.
Im Anhang meine Systeminformationen, Informationen zum USB-Stick (beide HWInfo) und das Log das DiskImage 12 beim fehlgeschlagenen Wiederherstellungsversuch auf USB-Stick produziert hat. Screenshots habe ich keine gemacht ... die wären aber sowieso äußerst unspannend gewesen. Eben Sicherung wählen, Zielgerät wählen, Start. Wollen Sie löschen? Ja Wollen Sie löschen? Ja Wollen Sie löschen? Du kannst mich mal... Wiederherstellung abgebrochen. Stick-Dateisystem RAW. Sicherungsdatei lag in diesem Fall lokal. Soweit ich gesehen habe steht das alles auch im XML-Bericht.

Die Hardwareberichte enthalten falls nötig bergeweise mehr Informationen.

Mit beschädigt meinte ich schon eher das Dateisystem. Ich wusste nur eher nicht ob DiskImage das bewusst überschrieben hat (wie Sie es skizziert haben) oder ob das Programm eher unabsichtlich das vorherige Dateisystem beschädigt hat.

Kurz gesagt: Windows 8.1 x64 und ein USB2-Stick. Einen Hardware-Defekt am USB-Stick kann ich (jedenfalls bis zu diesem Punkt) relativ gut ausschließen denn ein Backup-Restore-Vorgang dieses Sticks ist mit meiner sonst eingesetzten Version von DiskImage (10.6.167.0) auf dem selben System kein Problem. Das habe ich schon recht oft gemacht.
Dateianhänge
Gescheiterter Restore auf USB-Stick.xml
(23.49 KiB) 35-mal heruntergeladen
System und Hardware.LOG
(146.96 KiB) 35-mal heruntergeladen
USB-Stick.txt
(664 Bytes) 32-mal heruntergeladen
Zuletzt geändert von cookie am Sa 10. Mär 2018, 22:58, insgesamt 5-mal geändert.

cookie
Beiträge: 7
Registriert: Mi 28. Feb 2018, 21:42

Re: Diverse Bug-Reports zu DiskImage 12 v129

Beitrag von cookie » Sa 10. Mär 2018, 18:45

Problem mit der CLI-Variante
Exkludiere ich einen Ordner mit /exclude "ordner", gibt es ihn wirklich optisch danach im Backup nicht mehr. Die Erstellung des Backups dauert aber genauso lange wie ohne exclude und das Backup ist auch plusminus ein paar Byte genauso groß wie das ohne Exklusion. Der exkludierte Ordner war riesig. Mit Exklusion war das Backup kaum mehr als Luft und hätte entsprechend klein sein müssen.
Welches Format der dateibasierten Sicherung oder welches Format der sektorenbasierte Sicherung haben sie gewählt ? Bei einer sektorenbasierten Sicherung werden die Datenbereiche der ausgeschlossenen Dateien nicht übernommen. Bei einer dateibasierten Sicherung werden die Dateien nicht in der Sicherungsdatei aufgenommen. Im ersten Fall wird die Sicherung nur viel kleiner, wenn die ausgeschlossenen Dateien entsprechend groß sind. Bei vielen kleinen Dateien, können die Daten der Dateien im Dateisystem selbst liegen.
Der Befehl war
oodicmdc.exe /create image /source E:\ /destination D:\Testbackup.omg /password 123 /exclude "sources"
Laut Dokumentation https://docs.oo-software.com/de/oodiski ... rderung-12 ergibt das dann used sector.

Sofern ich Sie richtig verstehe hätte es aber eigentlich gar keine Rolle spielen dürfen ob nun sector oder file. Es war ein Backup des auch in anderen Problemen thematisierten USB-Sticks. Darauf war zu dieser Zeit ein Windows 10 1710-Setup aufgespielt. Besagte Exklusion war das "sources"-Verzeichnis. Das macht gut und gerne 99% des Umfangs eines Windows-Setups aus und das wiederum hat fast diesen ganzen Platz in einer Datei (install.esd) konzentriert.
Egal ob nun die Dateien darin ausgenommen wurden oder die Sektoren: In beiden Fällen hätte das Backup nur noch ein paar Megabyte haben dürfen. Es hatte aber die vollen rund 3,5 GB die ein Windows-Image heute so hat und es dauerte auch genauso lange als würde gar keine Exklusion stattfinden. Beim Mounten des Backups wurden nur die paar Rest-Dateien angezeigt, aber der Platz wurde sehr wohl belegt.

Das Backup ist auch nicht kompressibel. Daraus schließe ich dass es nicht nur heiße Luft / Platzhalter sind sondern dass wohl alles bis auf die Dateisystemeinträge gesichert wurde ... womit das exclude relativ sinnlos wäre.
Zuletzt geändert von cookie am Sa 10. Mär 2018, 22:52, insgesamt 7-mal geändert.

cookie
Beiträge: 7
Registriert: Mi 28. Feb 2018, 21:42

Re: Diverse Bug-Reports zu DiskImage 12 v129

Beitrag von cookie » Sa 10. Mär 2018, 20:06

Falsche Disk-Zuordnung
Wie erwartet kam eine Abfrage ob ich den Datenträger wirklich überschreiben will. ABER: Die Angabe, welche Partitionen ich dabei löschen würde, war die, dass auf diesem Datenträger gar nichts drauf wäre. DiskImage hat mich also visuell den USB-Stick auswählen lassen, bei der Wiederherstellung aber die !externe Festplatte! ausgewählt. Böses Foul. Wenn hier jemand nicht ganz genau hinsieht kann das sehr böse enden.
Unsere QA hat versucht das Verhalten zu reproduzieren, ohne Erfolg. Eine solcher Anzeigenfehler könnte in der Tat Probleme bereiten. Haben Sie evtl. Screenshots gemacht, damit wir das Problem eingrenzen können? Die Protokolldatei des Dienstes sowie der UI würden wir ebenfalls benötigen.
Einen Screenshot hatte ich keinen gemacht, auch weil das für sich gesehen keinen Informationswert hatte. Man sah halt dass ich den Stick als Ziel angewählt hatte und ein Fenster das mich fragte ob ich wirklich löschen will - und auf eine leere Liste von Partitionen verwiesen hat. Wirklich hilfreich wäre hier eigentlich nur ein Video gewesen... aber dafür war es schon lang zu spät. Auf Reproduktion hatte ich hier keine Lust ... ich wollte mein Glück nicht herausfordern.

Für die QA versuche ich aber noch einmal eine Schilderung des Hergangs:
-DiskImage gestartet. Stick war noch nicht eingesteckt
-F5 um die Laufwerke zu aktualisieren. Ggf. auch mehrmals.
-Sicherung und Stick als Ziel gewählt
-Es kam eine Abfrage dass dieser Vorgang die Disk überschreiben wird und ob ich das will. Aber eben nicht mit der Partition am Stick sondern mit einer leeren Liste. Obwohl am Stick zu der Zeit noch eine Partition vorhanden war.

Mir ist später eher zufällig aufgefallen dass die Windows-Datenträgerverwaltung ein spukhaftes Laufwerk anzeigte. Eine Festplatte, aber eben ganz ohne Partitionen darauf. Das sah genauso aus wie bei einem Kartenleser der noch keine SD-Karte enthält, nur aber eben als "Festplatte". Ich habe einen Screenshot beigelegt, auch wenn das leider nur der Fall "Kartenleser" ist. Die spukhafte Disk glaube ich schon öfters gesehen zu haben, aber ich kann sie nicht gezielt reproduzieren.

Wenn ich diesen Fehler suchen müsste, würde ich mir vermutlich ansehen ob alle Stellen im Code sauber mit so einem leeren "Gerät" umgehen. Der Fehler wirkt auf mich ein wenig so als ob die Liste der Oberfläche und die Wiederherstellungs-Routine das Gerät mal als solches in ihrer Reihenfolge berücksichtigen und mal nicht. Und dann eben die Auswahl und das zu löschende Device auseinanderdriften.

Protokolle:
-Von DiskImage kenne ich bislang vor allem die XML-Dateien in C:\ProgramData\OO Software\DiskImage\Berichte. Da scheint es so als wäre kein Bericht generiert worden. Das gäbe auch irgendwo Sinn, denn den Restore habe ich ja wegen der fragwürdigen Partitionsliste schon abgebrochen bevor er richtig gestartet wurde.
-Falls das "UI"-Protokoll ein anderes ist müsste ich wissen wo das liegt
-Was meinen Sie mit "Protokolldatei des Dienstes"? Falls Windows-Eventlog: Dort gibt es leider bereits keine Daten zu diesem Zeitbereich mehr. Aber ich glaube dass dass ich das bei den damaligen Problemen des öfteren selbst angesehen habe. Es war leider nichts hilfreiches enthalten.
Dateianhänge
Disk ohne Medium.PNG
Disk ohne Medium.PNG (9.51 KiB) 2251 mal betrachtet

cookie
Beiträge: 7
Registriert: Mi 28. Feb 2018, 21:42

Re: Diverse Bug-Reports zu DiskImage 12 v129

Beitrag von cookie » Sa 10. Mär 2018, 20:21

Zu Ihrem Abschluss:
Wegen der Fehler oben war das nicht vernünftig testbar. Aber ich bin über viewtopic.php?f=27&t=4316 gestolpert. Dass man das dort einfach als Einschränkung abgebügelt hat, hat mich ziemlich sprachlos gemacht. Vor allem weil keinerlei Erklärung gegeben wird.
Diese Aussage wird vom Support gegeben, um nicht jedes netzwerkfähige Laufwerk supporten zu müssen. Wir selber haben mehrere NAS Systeme für Homekunden zu testzwecken im Betrieb. Die meisten Kunden erwarten, dass alle Programme sofort mit jedem Netzwerklaufwerk erfolgreich arbeiten können. Da O&O DiskImage ein Dienst ist, welcher im Systemkontext laufen muss, kann dieser Dienst nicht im die Benutzerkontext angeschlossene Laufwerke „sehen“. Wir versuchen die in der UI ermittelten gemounteten Netzlaufwerke aufzulösen und die notwendigen Anmeldeinformation zu erfragen, um auf die Geräte zugreifen zu können.
Des Weiteren ist der Mounttreiber ein virtueller Gerätetreiber, welcher eine Disk simuliert. Wenn ein Gerät unter Windows nicht schnell genug antwortet, kann es passieren, dass Windows das Gerät abmeldet, da es von einem fehlerhaften Gerät ausgehen muss. Im schlimmsten Fall kann es zu einem BSOD kommen, wenn ein Dateisystem- oder ein Filtertreiber davon betroffen ist. Um Problem dieser Art zu vermeiden, wird die Aussage getroffen, die Sicherungsdateien lokal vorzuhalten.
Das gilt übrigens nur für die Mountfunktionalität. Eine Wiederherstellung, egal welcher Art und egal von welcher Sicherungsdatei, kann ohne Probleme von externen oder Netzlaufwerken durchgeführt werden!
Danke für diese ausführliche Erklärung. Damit gibt die Einschränkung beim mounten Sinn.
Ganz glücklich ist es trotzdem noch nicht: Wer das ganze System backuped wird nur in den seltensten Fällen auch noch Dateibackups machen, schließlich sind die sowieso schon im Backup enthalten und das Backup-Ziel wird auch so schon schnell genug voll. Im Zweifel hätte auch ich lieber mehr Backuptiefe als ein redundantes System- und Dateibackup. Wenn sich dann jemand nicht gleich das ganze System zerschießt sondern nur eine Datei hat er dann bei einer Netzwerklösung ein Problem. Dann wäre man wieder beim Umschichten von Backups. Im günstigen Fall kostet das Zeit (und gerade bei einem "Datei weg" neigen die Leute dazu, diese Geduld erst recht nicht zu haben), im schlechteren Fall hat man gar nicht mehr genügend lokalen Speicher - Stichwort kleine SSDs. Auch ich frage mich jedes Mal warum ich eigentlich noch so viele lose HDDs herumliegen habe wenn ich eine gut ausgebaute NAS habe... und wegen eben der braucht man eigentlich auch keine riesigen SSDs.

Für so etwas wäre irgendeine Art von Mounten, Extraktion oder was auch immer schon wünschenswert. Kann sein dass auch "Extraktion" schwierig ist weil DiskImage dazu die Rohdaten selbst interpretieren können müsste. Notfalls könnte man auch eine "auf eigenes Risiko" Option einbauen. Oder man legt das gleich als fortgeschrittene Option in die CLI und baut dort nochmal eine lange Warnung ein. Da könne man noch am ehesten erwarten dass derjenige so etwas auch versteht. Dann könnte man immer noch entscheiden ob man das Risiko eingehen will. Mir persönlich wäre ein kleines BSOD-Risiko immer noch sehr viel lieber als an eine Datei gar nicht heranzukommen weil ich nicht genügend lokalen Speicher habe um die Backups lokal zu machen. Zumal man je nach NAS-Aufbau ggf. sehr einfach abschätzen kann wie groß das Risiko ist dass die ausgerechnet dabei ausfällt. Das Problem könnte ich genauso gut haben wenn ich ein Backup von einer externen HDD lade und die abschalte ohne das Backup zu unmounten.
Bislang bekomme ich egal ob ich über DiskImage selbst oder über den Windows-Explorer gehe nur einen kryptischen Fehlercode der nicht direkt nahelegt dass das eigentlich eine gut gemeinte Sicherheitsmaßnahme ist.

Ich hatte das aber auch aus gutem Grund als mehr als nur Mounten interpretiert: Es betraf mindestens früher auch den Restore: Ein Restore eines Vollbackups von NAS funktioniert, aber sobald auch nur eine kleine Kette von Backups vorliegt, scheitert es. Meine Erfahrung war eben: Ich darf auf NAS gerne Backups ablegen und kann auch gerne inkrementelle Backups davon bilden. Aber ein Restore mit Boot-CD ist in dieser Form nicht möglich. Ich musste in der Vergangenheit dann eben dazu übergehen, im Fall der Fälle erst einmal die Daten herunterzuladen, lokal zu mergen und dann das wiederherzustellen.

So ein Restore kommt (zum Glück) bei mir nur sehr selten vor.
Ich habe es in einer VM mit Boot-ISO getestet. Das Backup von damals lag mitsamt einer entsprechenden Notiz noch herum. Das Problem hatte ich wohl mit Version 9, Ende 2015. Damals kam es lt. meiner Notiz dazu dass DiskImage mich endlos nach dem Basisbackup ausfragte obwohl das im selben Verzeichnis lag. Soweit ich mich erinnere hatte ich hatte das Phänomen auch danach nochmal, aber bei diesen Backup-Dateien habe ich immerhin Gewissheit dass es noch exakt die sind die damals Probleme machten.

Meine VM-Tests ergaben heute:
-DiskImage 10.5 war damit auch noch nicht glücklich. Es meckerte dass sich im Backup irgendwelche Daten geändert hätten und dass das auf eine Beschädigung hindeuten würde. Habe es nicht vollständig durchlaufen lassen, aber die Erfolgsaussichten schienen mir mit der Fehlermeldung sowieso nicht die besten zu sein.
-DiskImage 12 hat die Dateien klaglos akzeptiert und das Backup war uneingeschränkt erfolgreich. Das System konnte danach aus eigenen Stücken booten.
Irritierendes Detailproblem: Das Boot-Image von Version 12 erkennt sein eigenes Startverzeichnis "X:\" als Disk 1. Beim Restore auf Disk 0 (meine virtuelle Test-Disk) meckerte es bei mir am Ende herum dass es den Bootsektor von Disk 1 nicht aktualisieren konnte. Für das Ergebnis spielte es keine Rolle, aber es irritierte einfach. Das stand einfach unter Warnings. Kein Fehlercode.
Außerdem scheint es so als ob DiskImage im Boot-CD-Betrieb keine Berichte erzeugt. (Ironischerweise habe ich dort in ProgramData-Verzeichnis aber die UILog-Datei gesehen die ich auf meinem lokalen PC nicht gesehen habe).

Insgesamt scheint DiskImage bei Netzwerkpfaden / NAS in Version 12 wirklich besser aufgestellt zu sein als früher - auch wenn man das nicht an die ganz große Release-Glocke gehängt hat.
Für das Mounten, extrahieren oder wasauchimmer fände ich irgendeine Alternative zum "geht nicht" sehr sinnvoll. So muss ich trotz allem für die Anwender die ab und an auch mal eine Datei wiederherstellen müssen wieder lokale externe Festplatten aufstellen anstatt das auf einen Netzwerkspeicher zu stellen bei dem ich ganz andere Möglichkeiten habe das nochmal querzusichern.

cookie
Beiträge: 7
Registriert: Mi 28. Feb 2018, 21:42

Re: Diverse Bug-Reports zu DiskImage 12 v129

Beitrag von cookie » Sa 24. Mär 2018, 11:50

14 Tage nach den geforderten Details - keine Reaktion.
Ich respektiere wenn das nachrangig behandelt wird. Vielleicht braucht manches auch intern etwas Zeit bevor man eine Antwort geben möchte.

Jedenfalls werde ich künftige neue Haupt-Versionen daran messen ob/wie stark man diese Punkte berücksichtigt hat. Die Fixes würden sich eigentlich auch in eine Nebenversion gehören, aber mir fehlt schlicht die Zeit diese alle zu testen.

Antworten