Hallo allerseits,
eine kleine Warnung - bei einem Festplattenwechsel nach einem headcrash in meiner DS 216+II bin ich auf verschiedene Probleme beim Restore von Hyperbackup gestoßen, sowohl mit Hyperbackup selbst als auch mit dem Hyperbackup Explorer unter Windows.
Dem Synology Support habe ich das alles bereits mitgeteilt, aber ich habe nicht das Gefühl das die Probleme dort so richtig ernst genommen wurden.
Vorab: das Backup ansich düfte in Ordnung sein, auch der Integrity check findet keinen Fehler.
Aber das Restore war ein einziges Fiasko:
Als erstes habe ich versucht, das Backup vom PC aus mit dem HyperBackup Explorer wiederherzustellen (war nur als zusätzliche Sicherung gedacht)
Hier gab es bei vielen Ordnern beim wiederherstellen eine Fehlermeldung "Operation fehlgeschlagen" (unheimlich aussagekräftig...)
Nach einiger Sucherei (im Program gibt es keinen Hinweis darauf) habe ich dazu ein logfile gefunden, und zwar im Programmordner
"C:\Program Files (x86)\Synology\HyperBackupExplorer\HyperBackupExplorer.log"
(anscheinend hat Synology noch nichts davon gehört, das dort Daten nichts zu suchen haben?)
Zusammen mit dem Synology Support habe ich dann herausgefunden, was schiefgegangen ist:
der HyperBackup Explorer schreibt die wiederherzustellenden Dateien nicht etwa direkt in das ausgewählte Zielverzeichnis, sondern zuerst nach %TEMP% (im Benutzerordner!!), und zwar nicht Datei für Datei sondern ALLES auf einmal.
Die Bootplatte des Rechners (C:\) ist eine SSD mit „nur“ 512 GB (ca 100 GB waren frei) - hier passen natürlich keine großen Datenmengen (zb ein Ordner mit einigen Tausend Fotos) rein.
Das Ziellaufwerk war ja auch D:\ (HDD mit einigen TB frei ...) nur soweit kommt es dann erst gar nicht.
Das ist meiner Meinung nach „broken by design“ – man kann doch nicht davon ausgehen das im %temp% eines Benutzers genügend Platz für die Wiederherstellung eines ganzen Backups frei ist!
Außer diesem meiner Meinung nach massiven Fehler ist HyperBackup Explorer ein absoluter UI-Alptraum:
b) wenn man einen ganzen gemeinsamen Ordner wiederherstellen versucht, kommt nur die Meldung „Dateityp wird nicht unterstützt“
geht nicht
((
c) Man muss also mindestens die im root des gemeinsamen Ordners abgelegten Unterordner bzw. die dort liegenden Dateien kopieren.
Dazu gibt es dann aber nicht einmal eine Mehrfachselektion, man kann also immer nur ein einzelnes Verzeichnis oder eine einzelne Datei kopieren
Bei einigen hundert Dateien/Ordnern im root eines gemeinsamen Ordners sitzt man Stundenlang!
d) Das Hyper Backup Explorer Fenster hat eine fixe Größe, fixe Spaltenbreiten, und große Schrift
man sieht gerade 14 Dateien/Ordner (von hunderten)
und von denen nur die ersten paar Zeichen. Längere Dateinamen mit gleichem Anfang sind nicht unterschiedbar.
e) Sortieren nach Typ oder Datum ist auch nicht möglich (das muss nicht unbedingt sein, aber nice to have)
Restore auf der DS mit Hyper Backup
nach einbau der neuen Platte in die DS, habe ich dann dort direkt wiederhergestellt.
Der Restore-Lauf ist bei einigen gemeinsamen Ordnern (mit vielen Dateien, Fotos) mit der Meldung "exeption occured while restoring data" abgebrochen.
Als sich es dann ein paar mal wiederholt habe ist es dann doch irgendwann ohne Fehler durchgelaufen.
es gibt dazu ein Protokoll (in Hyper Backup keine Spur davon, aber immerhin im Protokoll Center), darin war ersichtlich das die fehlerhaften Dateien nur Thumbnails der Photostation waren.
Mehr konnte auch der Synology Support nicht herausfinden (warum kam der Fehler? warum hat es später dann doch funktioniert?)
Immerhin hat das Restore schlussendlich dann funktioniert, mein Vertrauen in dieses Backup stärkt das aber nicht gerade...
Auch dazu habe ich folgende "Verbesserungsvorschläge" an den Support weitergeleitet:
f) die fehlerhaften Dateien wurden vom Programm nicht angezeigt
ich erwarte mir da eine lesbare Fehlermeldung, und einen direkten Link zu dem Logfile wo man sieht was alles nicht ok war.
g) die Wiederherstellung hat nicht nur diese Dateien nicht wiederhergestellt, sondern wurde an dieser Stelle abgebrochen
Der halbe gemeinsame Ordner hat dann gefehlt
Das darf nicht sein, die Wiederherstellung muss mit den restlichen Daten weitermachen
h) es waren auch gar keine „echten“ Daten betroffen, sondern nur (für den User gar nicht sichtbare!) Thumbnails
Zumindest solche Daten sollten problemlos übersprungen (und dann neu erstellt) werden können
i) da bei wiederholten Versuchen dann ja doch das der ganze gemeinsame Ordner wiederhergestellt
Es muss also temporär etwas schiefgegangen sein (was auch immer - das muss herausgefunden werden!)
Hilfe brauche ich dazu keine mehr, vieleicht helfen meine Erfahrungen aber Anderen weiter, darum schreibe ich das hier.
Auf jeden Fall ist HyperBackup mit sehr viel Vorsicht zu genießen.
Das es um Welten langsamer ist als TimeBackup kommt ja auch noch dazu.
Vor allem beim Erstbackup - bei ca 2TB Daten lief es mehr als einen Tag. Die täglichen Updates sind erträglich.
Auch der Integrity check "mit Wiederherstellungstest" braucht da mehr als einen Tag, "ohne Wiederherstellungstest" läuft er "nur" etwa 8h
lg,
Martin
eine kleine Warnung - bei einem Festplattenwechsel nach einem headcrash in meiner DS 216+II bin ich auf verschiedene Probleme beim Restore von Hyperbackup gestoßen, sowohl mit Hyperbackup selbst als auch mit dem Hyperbackup Explorer unter Windows.
Dem Synology Support habe ich das alles bereits mitgeteilt, aber ich habe nicht das Gefühl das die Probleme dort so richtig ernst genommen wurden.
Vorab: das Backup ansich düfte in Ordnung sein, auch der Integrity check findet keinen Fehler.
Aber das Restore war ein einziges Fiasko:
Als erstes habe ich versucht, das Backup vom PC aus mit dem HyperBackup Explorer wiederherzustellen (war nur als zusätzliche Sicherung gedacht)
Hier gab es bei vielen Ordnern beim wiederherstellen eine Fehlermeldung "Operation fehlgeschlagen" (unheimlich aussagekräftig...)
Nach einiger Sucherei (im Program gibt es keinen Hinweis darauf) habe ich dazu ein logfile gefunden, und zwar im Programmordner
"C:\Program Files (x86)\Synology\HyperBackupExplorer\HyperBackupExplorer.log"
(anscheinend hat Synology noch nichts davon gehört, das dort Daten nichts zu suchen haben?)
Zusammen mit dem Synology Support habe ich dann herausgefunden, was schiefgegangen ist:
der HyperBackup Explorer schreibt die wiederherzustellenden Dateien nicht etwa direkt in das ausgewählte Zielverzeichnis, sondern zuerst nach %TEMP% (im Benutzerordner!!), und zwar nicht Datei für Datei sondern ALLES auf einmal.
Die Bootplatte des Rechners (C:\) ist eine SSD mit „nur“ 512 GB (ca 100 GB waren frei) - hier passen natürlich keine großen Datenmengen (zb ein Ordner mit einigen Tausend Fotos) rein.
Das Ziellaufwerk war ja auch D:\ (HDD mit einigen TB frei ...) nur soweit kommt es dann erst gar nicht.
Das ist meiner Meinung nach „broken by design“ – man kann doch nicht davon ausgehen das im %temp% eines Benutzers genügend Platz für die Wiederherstellung eines ganzen Backups frei ist!
Außer diesem meiner Meinung nach massiven Fehler ist HyperBackup Explorer ein absoluter UI-Alptraum:
b) wenn man einen ganzen gemeinsamen Ordner wiederherstellen versucht, kommt nur die Meldung „Dateityp wird nicht unterstützt“
geht nicht
((c) Man muss also mindestens die im root des gemeinsamen Ordners abgelegten Unterordner bzw. die dort liegenden Dateien kopieren.
Dazu gibt es dann aber nicht einmal eine Mehrfachselektion, man kann also immer nur ein einzelnes Verzeichnis oder eine einzelne Datei kopieren
Bei einigen hundert Dateien/Ordnern im root eines gemeinsamen Ordners sitzt man Stundenlang!
d) Das Hyper Backup Explorer Fenster hat eine fixe Größe, fixe Spaltenbreiten, und große Schrift
man sieht gerade 14 Dateien/Ordner (von hunderten)
und von denen nur die ersten paar Zeichen. Längere Dateinamen mit gleichem Anfang sind nicht unterschiedbar.
e) Sortieren nach Typ oder Datum ist auch nicht möglich (das muss nicht unbedingt sein, aber nice to have)
Restore auf der DS mit Hyper Backup
nach einbau der neuen Platte in die DS, habe ich dann dort direkt wiederhergestellt.
Der Restore-Lauf ist bei einigen gemeinsamen Ordnern (mit vielen Dateien, Fotos) mit der Meldung "exeption occured while restoring data" abgebrochen.
Als sich es dann ein paar mal wiederholt habe ist es dann doch irgendwann ohne Fehler durchgelaufen.
es gibt dazu ein Protokoll (in Hyper Backup keine Spur davon, aber immerhin im Protokoll Center), darin war ersichtlich das die fehlerhaften Dateien nur Thumbnails der Photostation waren.
Mehr konnte auch der Synology Support nicht herausfinden (warum kam der Fehler? warum hat es später dann doch funktioniert?)
Immerhin hat das Restore schlussendlich dann funktioniert, mein Vertrauen in dieses Backup stärkt das aber nicht gerade...
Auch dazu habe ich folgende "Verbesserungsvorschläge" an den Support weitergeleitet:
f) die fehlerhaften Dateien wurden vom Programm nicht angezeigt
ich erwarte mir da eine lesbare Fehlermeldung, und einen direkten Link zu dem Logfile wo man sieht was alles nicht ok war.
g) die Wiederherstellung hat nicht nur diese Dateien nicht wiederhergestellt, sondern wurde an dieser Stelle abgebrochen
Der halbe gemeinsame Ordner hat dann gefehlt
Das darf nicht sein, die Wiederherstellung muss mit den restlichen Daten weitermachen
h) es waren auch gar keine „echten“ Daten betroffen, sondern nur (für den User gar nicht sichtbare!) Thumbnails
Zumindest solche Daten sollten problemlos übersprungen (und dann neu erstellt) werden können
i) da bei wiederholten Versuchen dann ja doch das der ganze gemeinsame Ordner wiederhergestellt
Es muss also temporär etwas schiefgegangen sein (was auch immer - das muss herausgefunden werden!)
Hilfe brauche ich dazu keine mehr, vieleicht helfen meine Erfahrungen aber Anderen weiter, darum schreibe ich das hier.
Auf jeden Fall ist HyperBackup mit sehr viel Vorsicht zu genießen.
Das es um Welten langsamer ist als TimeBackup kommt ja auch noch dazu.
Vor allem beim Erstbackup - bei ca 2TB Daten lief es mehr als einen Tag. Die täglichen Updates sind erträglich.
Auch der Integrity check "mit Wiederherstellungstest" braucht da mehr als einen Tag, "ohne Wiederherstellungstest" läuft er "nur" etwa 8h
lg,
Martin
