Beiträge von ts453mini_LL

DANKE !!! der schnellen Reaktion!!

mmh, geht leider nicht. Was ich getan habe:

• HBS -> SICHERN UND WIEDERHERSTELLEN -> "Sicherungsauftrag neu verknüpfen"
• HBS fragt dann nach ZIELSPEICHERPLATZ. Da - so habe ich Dich verstanden - wähle ich meine "xxx.qdff" Datei aus - korrekt?
• wenn ich das tue, kommt die Warnmeldung "Die Sicherungsdaten des Ziels könnte mit einem bestehenden Sicherungsauftrag verknüpft sein. Nach der Neuverknüpfung kann dieser...nicht mehr...fortfahren?". Das klingt sinnvoll - ich klicke JA.
• Ich komme dann auf die Maske, in der als QUELLE links 4 Freigabe-Ordner vorausgewählt sind. Die scheint er aus der "qdff"-Dateie erkannt zu haben, sind nämlich angeklickt worden automatisch (insgesamt 34.000 Dateien). Ich weiß zwar nicht warum nur 4 der deutlich mehr Root-Ordner, aber sei's drum.
• Das Ergebnis ist unter HBS sauber gelisteter Sicherunsauftrag. Sieht erstmal gut aus

Das nützt mir aber gar nichts. Denn wenn ich jetzt auf "Wiederherstellen" gehe (was ja mein Ziel ist - nicht sichern auf die Platte, sondern ZURÜCKHOLEN aus der qdff-Datei - dann mault er:

"Auftragsfehler: Wiederherstellung aus diesem Auftrag nicht möglich. Dieser Auftrag wurde nicht erfolgreich abgeschlossen."

mmh..Möglichkeit 1 = damals war das letzte Backup korrupt. Möglichkeit 2 = ich hab sonstwas falsch gemacht. Möglichkeit 3 = HBS hat einen Bug.

Ausgangslage:

• Über HBS3 habe ich seit Monaten ein Versionbackup auf eine externe HDD. Ist meine dritte Backup-Ebene - alle 4 Wochen kommt die HDD dran, wird autom. erkannt und ich stoße aktiv ein (inkrementelles) Backup an. Und zwar über einen in der HBS3 fest angelegten Job (in dem die Quellordner, etc alles definiert wurde). Soweit so gut.
• Ich hatte zwischenzeitlich einmal "Wiederherstellen" ausprobiert - ging....solange der Job-Eintrag in HBS3 vorhanden war(!) konnte ich die jeweiligen Zeitstempel abrufen und die Daten restaurieren. Soweit so gut.

Problem:

• Ich hatte mit HBS bei anderen Jobs massive Probleme und hatte das deswegen komplett als App gelöscht - und neu installiert.
• HBS war danach wieder jungfräulich - und damit auch ohne Jobeinträge.
• Ergebnis: Als ich die ext. Backup-HDD das nä. Mal angeschlossen hatte, gab es keinen voreingestellten Job mehr dazu
• Der HDD-Inhalt ist noch sichtbar. Und zwar wie folgt: Quellordner "qdff". Darin verbergen sich die beiden Dateien "QnapHybridBackupSync.info" und "Qnap...db", sowie ein DEDUP Ordner und ein FILEDESC. Darin wieder die diversen inkrementellen Backups - aber erwartungsgemäss kryptisch und nicht im Zugriff
• Ich habe dann einen NEUEN Wiederherstellungsjob angeschoben unter HBS3. Blöd: Er läuft zwar, aber scheint nur eine 1:1-Kopie dieser Ordnerstruktur aufzubauen im Restore-Laufwerk. Normalerweise würde ich ja auswählen können WELCHE der Versionsbackups ich haben möchte

Komme ich da noch irgendwie ran?

In diesem Fall ist es mir wurscht weil nur 3. Sicherungsebene...aber es muss doch einen Weg geben, die ursprünglichen ORderstrukturen wieder hinzubekommen - auch ohne den "originalen" Jobeintrag in HBS3, oder ? (es gibt auc heinen lost+found Order im root der ext. HDD, aber da wird gemault der Zugriff sei nicht möglich).

Anders formuliert: wenn mir das originäre HBS abraucht, dann kann ich generell meine Backups in die Tonne treten? Oder ist das ein Problem von inkrementellen Backups und "normale" 1:1-Sicherungskopien funktionieren auch bei resettetem HBS?

Herzliche Grüße

Danke sawachika! Das von @DocHT beschriebene Tool hatte ich auch schon in alten Threads gefunden und bereits im Einsatz - das war oben in Screenshots. Leider wie besprechen nichts an Content auffindbar.

Ich werde jetzt meine HDD3 einfach ausbauen, unter WIN formatieren und dann dort alles auslagern als Backup. Sicher ist sicher. Oder mal gucken ob ich mir ein Ubuntu virtuell auf den Windows PC installiere vorher - so könnte es ja auch klappen.

Hallo. Nach intensiver Suche (und erfolglosem Durcharbeiten diverser teilweise jahrealter Threads hier im Forum) konnte ich noch keine Lösung zu folgendem HDD Auslesen einer QNAP Einzelplatte via WindowsPC finden:

HW und Volume-Konfig:

TS-453mini mit aktueller FW und 3x3TB WD Red. Die Platten sind so konfiguriert: HDD1 und HDD2 bilden ein verschlüsseltes RAID1, HDD3 ist unverschlüsseltes Single. HDD3 wird als internes Backup von RAID1-Daten via old-school "Sicherungsmanager" App stündlich aktualisiert.

Ausgangslage:

* meine "TS-453mini" (mit aktueller FW) zeigte seit Monaten CPU-Lastprobleme. Häufig >90% Auslastung, QSirch indiziert nach Neustart 2 Wochen mit rund 40% durchgehend! gerade mal 2TB - was früher nie ein Thema war. Aber auch nach De-Install von QSirch immer wieder Probleme.

* Ich befürchte mei einem der letzten Firmware-Updates hat sich was zerschossen, evtl. weil ich zuvor verschlüsselten Pool nicht erst entschlüsselt hatte. Daher: Ziel ist jungfräuliche (komplett!) NAS aufzusetzen. also alle APps runter, etc etc - weil QNAP Support meinte evtl ist mal in tiefen schichten zerschossen.

* Die Daten von RAID1 habe ich extern gesichert - und ich habe ja auch noch die HDD3 Platte mit komplettem Backup.

* jene HDD3 wollte ich nun mal an einen WIN-PC per USB anklemmen - um mal zu checken ob lesbar. DENN wenn irgendwas (Pferde vor Apotheke...) mit meinem externen Backup schief läuft, dann ist die HDD3 meine Lebensversicherung ALLER Daten! Muß also auch notfalls ohne die QNAP am WindowsPC lesbar sein. Ich befürchte z.B. das nach Neuaufsetzen die QNAP die HDD3 nicht mehr erkennt und zwangs-formatiert.

Problematik:

* Leider ist die HDD3 am Windows PC zwar lesbar - aber kein der eigentlichen Daten-Inhalte auffindbar! !

* Screenshot File Station: Die typische Backup-Ordnerstruktur ist zu erkennen mit den vielen Änderungsordnern und (nicht sichtbar) die aktuellste Daten-Version im Ordner "LATEST".

* Screenshot Windows Explorer: Die Einzel-HDD3 wird mit diversen Laufwerken eingebunden, aber nicht lesbar

* Wenn ich LinuxReader nutze, erkennt dieser die HDD3 (Volumen 1-4 sowie ganz oben /dev/ und /Mnt/. Zur Klärung: Es werden auch die beiden internen Festplatten C: und D: des WindowsPC sowie ein der 8GB USB-Stick angezeigt

Auf der HDD3 sind laut QNAP Storage Station ca 1.5TB Daten drauf....wo bitte sind die denn jetzt zu "greifen", sprich: im worst-case runterzuziehen ?

Ich habe alle Ordner im LinuxReader durchgeschaut. ist zwar alles öffnenbar (und auch kopierbar!)...aber ich finde meine Daten nicht!, nur paar APK, etc und diverse Linux-Befehls-Dateien..

Ich hoffe auf Tipp. Noch kann ich die HDD3 im NAS einlesen (weil noch nicht platt gemacht). Ist also eventuell das problem das genutzt RTRR Sicherungsformat? Sprich: Wenn ich HDD1+2 komplett mal sauber 1:1 rüberkopiere auf die HDD3, dann würde es gehen?

Hallo. Datenverlust, selbstverschuldet :-(.

Ursache: Wollte Daten eines USB-Sticks auf das NAS hochladen. Dazu den USB-Stick vorne in die NAS rein und via Sicherungsmanager ("External Backup - Externer Datenträger") wollte ich die Daten hoch KOPIEREN. Blöderweise war ich zu mutig und hab den Auftrag vom anderen Ende der Welt aus angelegt. Dazu die QManager App via Smartphone genutzt. Leider ist dabei ja (a) kaum was auf einen Blick zu erkennen weil man wild rumscrollen muß und (b) war ich über VPN im Heimnetz drin und daher auch noch verzögerter Bildschirmaufbau. Ergebnis: Das bei mir auf Default gestellte Häckchen "Überschüssige Dateien löschen" hat dazu geführt - logischerweise -, daß die USB-Daten nicht in den Order XXX dazukopiert wurden, sondern SÄMTICHE ZUVOR DARIN ENTHALTENEN ORDER UND DATEN GELÖSCHT HAT. Also nicht inkrementell.

Die gute Nachricht: Mein letztes Snapshot ist erst 7d alt.
Die schlechte Nachricht: Mein letztes Snapshot ist schon 7d alt

Hat noch jmd eine Idee für Recovery der ursprünglichen Ordner und Einzeldateien (ggf auf Linux-Ebene rumwurschteln nötig? Das kann ich nicht mehr. Aber mein Schwager ist Linux-Profi). Habe seither nichts mehr angefasst, aber könnte natürlich sein, daß die USB-Daten zumindest teilweise sektor-überschrieben wurden.

Vorhandene HW: TS-453mini mit 16GB
Platten: 2x 3TB WD Red im RAID 1 Verbund
Poolaufbau: 1 Speicherpool ThinVolume mit 3 Volumes. Das betroffene Volume ist nicht AES gekryptet.
Firmware: 4.2.2 mit Build vom 02.11.2016