Überschriebene Datei ohne Snapshot wiederherstellen

International
,
1

Jetzt ist es mir auch mal passiert, ich habe Daten versehentlich überschrieben die noch nicht im Backup enthalten waren …

Ich habe mit yt-dlp einen Livestream heruntergeladen (der leider auch im nachhinein nirgendwo als VOD verfügbar ist sondern nur einmalig live war):

yt-dlp -o “livestream.mp3” https://example.com/live

Eigentlich ganz einfach. Lief auch 6 Stunden lang prima und hat den Livestream aufgezeichnet. Problem war nur, nach 6 Stunden ist die HTTPS-Verbindung zum Server abgebrochen, und yt-dlp hat sie neu aufgebaut. yt-dlp “wusste” aber anscheinend nicht dass es sich dabei um einen livestream handelt - hat vom Server die Meldung bekommen “resume ist nicht” - und hat angefangen, den Livestream neu von dem Zeitpunkt an herunterzuladen. In die gleiche Datei. Und damit waren die ersten 6 Stunden des Livestreams weg und ich habe jetzt nur noch eine Datei mit den letzten beiden Stunden …

Ich habe, als ich das gemerkt habe, sofort den Server heruntergefahren und nichts weiter mehr gemacht.

Hat jemand eine Idee, wie ich das vielleicht noch wiederherstellen kann? Ich habe auf Reddit diese Anleitung gefunden, aber ich bin mir nicht sicher, ob das auch dann funktioniert, wenn es um überschriebene / truncated-Dateien geht die dann wieder neu mit anderem Inhalt gefüllt wurden …

Der Artikel redet auch von “if it has been too long since your “event” you may be out of luck” - aber wie lange ist denn “too long”?

Der zweite Teil des Downloads der die Datei wieder überschrieben hat lief so ca. 2 Stunden. In dem Zeitraum sollten aber eigentlich nur sehr wenige bis gar keine anderen Schreibzugriffe auf das Dateisystem erfolgt sein. Gibt es da Erfahrungsberichte, wie lange sowas klappt und ab wann es eher aussichtslos wird?

Bei “normalen” Dateisystemen (nicht ZFS) würde ich jetzt hingehen und erstmal von jeder Festplatte ein vollständiges Festplattenimage erstellen - das wird aber bei einem Raidz2 mit insgesamt ~120 nutzbaren TB eine sehr teure und lange Angelegenheit.

Ich dachte mir bevor ich jetzt einfach irgendeiner Reddit-Anleitung folge, frage ich hier lieber mal nach … dadurch dass der Download ja auch gerade erst noch lief, sind die Dateien halt auch nicht in meinen üblichen Backups drin, d.h. die einzige Chance ist, die doch noch irgendwie aus ZFS rauszubekommen …

Habe ich da selber noch irgendeine Chance? Oder muss ich den Kram zu einem Datenretter schicken und €€€€ bezahlen wenn ich das wiederhaben will? Ich habe dieses Tool hier gefunden für $400 - hat damit jemand Erfahrung und weiß ob das wirklich so vernünftig funktioniert?

Ist das im Reddit-Artikel erwähnte Readonly-mounten wirklich 100% read-only, d.h. wenn ich das ausprobiere kann ich es zumindest nicht schlimmer machen als es aktuell ist?

Wenn ich aber jetzt das TrueNAS-System wieder einschalte, wird der das Dateisystem nicht automatisch wieder r/w mounten? Wie kann ich das verhindern? Platten ausstecken und erst nach dem Systemboot wenn die UI wieder da ist wieder einstecken?

2

Ich habe mir die Links nicht angeschaut, nur es sind für mich Fragen offen:

  1. warum hast du direkt auf dem NAS den Stream gesichert
  2. bist du sicher das es den stream nirgend zum download gibt (um was ging es denn, das tool yt-dlp ist doch für youtube)?
  3. Vom gefühl her würde ich sagen, du hast keine chance noch an die daten zu kommen, die sind überschrieben. Wenn es doch geht währe ich überrascht
3

Depends how many transactions groups (TXG) have been issued.

Other than some lucky import (using a TXG #), I don’t see how you can recover the temporarily-written large audio file.

4

@micneu
Warum ich die Daten direkt auf dem NAS gespeichert habe? Gegenfrage, warum nicht? Das NAS ist per NFS an meinem PC angebunden und bisher gab es da auch keine Probleme mit. Und auch jetzt das Problem ist ja nicht dadurch entstanden dass ich die Datei direkt auf dem NAS gespeichert habe, der Fehler in yt-dlp wäre ja auf der lokalen Platte genauso passiert. Da wär’s dann halt ein ext4-Dateisystem auf meinem Linux-PC gewesen, keine Ahnung ob das ein Recovery einfacher oder schwieriger gemacht hätte, aber es hätte am Problem nix geändert.

yt-dlp wurde ursprünglich für YouTube entwickelt, kann aber mittlerweile auch Videos und Streams auf tausenden anderen Webseiten herunterladen.

@winnielinnie
So basically, I need to figure out if there’s still a transaction group on the drives from before the file was truncated? How often are these created / how long are they usually kept? Are they created by time (every X seconds / minutes) or by data written (every X MB), or by files written / modified (every X writes)?

What is the best way to figure that out without potentially overwriting more data? Pull drives, boot machine, make sure all automounts and stuff are disabled then add back the drives? I don’t want to just boot TrueNAS scale again so it doesn’t automount the pool back in r/w mode and possibly cause more damage …

5

On average, it’s about every 5 seconds.

So I’m not sure how far back you can attempt an emergency import. It might even backfire.

Why isn’t the stream still available for download?

6

Die Wiederherstellung laut Reddit Post funktioniert nur, wenn nicht allzuviele Schreibzugriffe erfolgt sind – steht so auch da bzw. im Originalpost von /u/volopasse auf Reddit.

Szenario wäre: Oh Mist, Datei gelöscht, schnell Rechner runterfahren und Rettung starten.

Mit 2 h kontinuierlichem Schreibzugriff eines fetten Videostreams hast du wohl weniger Chance als ein Schneeball in der Sonne.

yt-dlp tut das, was du ihm sagst. Mit einfach -o <Dateiname> wird angenommen, dass bei erneutem Schreiben wieder in die Datei geschrieben werden soll, das ist das Default Template.

Wenn du -o %(epoch+7200>%Y-%m-%d_%H-%M-%S)s_<Dateiname> nimmst, hätte yt-dlp jedesmal eine neue Datei angelegt, die Datum und Uhrzeit der Dateierstellung vorangestellt hat. Das steht so auch in der manpage von yt-dlp.

Damit hätte das problemlos geklappt. Dann hättest du mehrere Streamdateien gehabt, die du hättest zusammenführen können.

Für dich zum Trost: Ich weiß das, weil ich selber auch schon mal so einen Fehler gemacht habe. Du bist nicht allein.

1 Like
7

Das hat es ja leider eben nicht getan.
Genau den Befehl habe ich genutzt (habe es nur im ersten Post ein bisschen vereinfacht dargestellt mit “livestream.mp3”).

Der hilft, wenn yt-dlp abschmiert und dann neustartet, dann wird ein neuer Dateiname nach dem neuen Muster vergeben. Genau das habe ich extra vor dem Download getestet & dachte ich wäre auf der sicheren Seite. Wenn aber nur der HTTP-Stream abbricht und yt-dlp den im laufenden Prozess neu aufbaut, dann wird kein neuer Dateiname vergeben sondern die gleiche Datei mit alter Uhrzeit wieder überschrieben - und das steht so nicht in der manpage.

Aber trotzdem danke für die Antwort. Habe mittlerweile die Uberblocks geprüft und leider keinen passenden mehr gefunden.

8

OK, das ist wirklich blöd. Meine Oma hätte jetzt gesagt: “Man kann gar nicht so dumm denken, wie es dann kommt”.

Hätte --live-from-start geholfen? Da war ja offensichtlich nicht die Erkennung, dass es ein Stream war. Solltest du vielleicht mal als bug bei den yt-dlp Entwicklern melden.

9

Ich habe es nicht getestet, aber ich denke nicht dass das geholfen hätte.

yt-dlp wusste dass es ein Stream ist und hat ja auch versucht, den Download von anfang an wieder laufen zu lassen bzw. wieder aufzunehmen, hat der Server aber halt nicht unterstützt.