Ich versuche mit btrfs restore Dateien im home Verzeichnis wiederherzustellen. Dafür muss die entsprechende Partition nicht gemountet sein. Also boote ich mit anderer Installation und Platte. Der kernel verhindert bei btrfs scheinbar das ich auf das home Verzeichnis zugriff habe. Dadurch wird scheinbar auch der zugriff von btrfs restore verhindert, ich kann jedenfalls nichts neueres finden. Ich möchte gerne mein home Verzeichnis, bzw. ein einzelnes Verzeichnis im home Bereich so ändern, das der kernel genau das nicht mehr macht.
Es liegt doch nicht am home Verzeichnis, da ich btrfs restore nicht gleich verstanden habe nutze ich die Shell Datei btrfs-undelete https://gist.github.com/Changaco/45f8d171027ea2655d74#file-btrfs-undelete aber es wird auch eine frisch gelöschte Datei außerhalb des home Verzeichnis damit nicht gefunden.
Ich will den Ordner Dokumente im home Bereich wiederherstellen. weiß zufällig jemand auswendig wie man btrfs restore dazu bringt, das wäre sicher für viele interessant da ich sagenhafterweise zu diesem alltäglichen Problem nichts finden konnte.
also ich konnte jetzt folgendermaßen eine liste mit wiederherstellbaren Dateien erzeugen. Warnung sie landet an dem ort der im terminal steht und nicht an dem den ich folgend angegeben hatte und sie wird ca. 800mb pro 100gb Partition groß: btrfs restore -s -v -D /dev/sda2 /run/media/al/67918311-dcd2-4f9a-a836-cqba8fd93137/0Dateien >0.txt
leider brauche ich damit nicht weiter zu probieren, denn es konnte nichts was ich brauche gefunden werden.
ext4 ist weiterhin Müll und macht Fehler, selber erst vor kurzem erlebt. btrfs ist damit auch disqualifiziert. ich hatte zwar noch ein paar GB geschrieben, war aber fest davon überzeugt das btrfs das nicht versaut. Aber es findet NULL aus dem Verzeichnis, außer bereits vorhandene von mir wiederhergestellte.
Also mein Fazit ext2 wie ich schon immer genommen hatte. Damit kann man etwas wiederherstellen und hat keine Fehler im betrieb wie bei ext4. In meinem ganzen leben hat noch kein Virus oder Hardwarefehler mir daten gekostet. Selber gelöscht habe ich schon oft etwas. Daher ist ganz klar ext2 zu bevorzugen, außer jemand wüsste das ext2 innerhalb von einer stunde ein trim ausführt in opensuse KDE. Ich werde es testen.
Auf weiteren Müll wie xfs habe ich jedenfalls keine Lust mehr, Müll da weiteres dateisystem und bis jetzt war alles schlechter als ext2.
Grade für eine SSD sollte ext2 sowieso keinerlei Nachteil zu ext4 haben.
Nur zu Verständnis – in ein Verzeichnis innerhalb ein Plattenbereich, der mit das Btrfs Dateisystem belegt ist, du hast probiert mittels „btrfs restore” Dateien die geschädigt worden sind, zu bergen – richtig?
# btrfs restore --root »subvolume ID« /dev/sdg2 /mnt/restore
- Unterplattenbereichsidentifizierung herauskitzeln wie folgt –
# btrfs restore --list-roots /dev/sdg2
Oder, hast du probiert Dateien die gelöscht worden sind, wiederherzustellen?
Normalerweise mittels Sicherungskopien – täglich Sicherungen durchführen …
- Linux und UNIX® verzeihen nicht – „rm” ist genau das – das Datei wird wegschafft – weggeräumt – die Dateien verschwinden …
Grafische-Oberflächen, normalerweise, sind mit ein Mülleimer ausgestattet …
[HR][/HR]Für Systemadministratoren, Werkzeuge wie „rsnapshot” und „timeshift” helfen Benutzer „versehentliche” verursachte Löschungen zu lindern …
[HR][/HR]Um sonst, wenn der Benutzer nicht ausgeloggt hat, Methoden mit „lsof” kann gelöschte Dateien wiederherstellen –
> lsof | grep »gelöschte Datei«
Zweite Feld ist, ein Prozess Identifizierung – ein Nummer – ein PID …
Vierte Feld ist ein Datei Deskriptor – ein Nummer –
> ls -l /proc/»*PID*«/fd/»*Datei Deskriptor*«
Einfach mit „cp” ohne Optionen ]] die Datei aus ‘/proc/’ nach ein Festplattenverzeichnis kopieren …
Wie alt ist die Festplatte?
Welche S.M.A.R.T. Fehlern hat Festplatte gemeldet?
[HR][/HR]Ja, „extundelete” ist nicht perfekt aber, wenn kein Sicherungskopie vorhanden ist, besser als nichts …
Nur weil XFS bietet kein „undelete” an?
- Die XFS Leute reden Klartext – „Sicherungen – Sicherungen – Sicherungen … ”
Aber, ohne ein Buchungsjournal ist ein Dateisystem in Nachteil – wenn kein Buchungsjournal aktiv ist, Stromausfälle und Systemabstürze führen zu Dateikorruption …
- Deswegen, frage Ich nicht warum ein fehlende Buchungsjournal vorteilhaft ist …
Eine elegante Lösung dazu bietet XFSv5 mit “XFS Reflink”:
Und funktioniert erst noch mit “normalen” Benutzerrechten…
=> Kein “su” oder “sudo” erforderlich!
=> Keine Kenntnisse über irgendwelche Super-Duper-Befehle erforderlich…
Dann kann man über xfs ja möglicherweise ohne su daten manipulieren, wenn einfach zugriff auf platte möglich ist?
ich hab jetzt folgendermaßen mir listen gemacht mit btrfs restore -s -v -D --root 256 /dev/sda2 /home/1/Downloads/0r >001.txt das fortlaufend bis 638. Dabei war kein Gewinn zu btrfs restore -s -v -D /dev/sda2 /run/media/al/67918311-dcd2-4f9a-a836-cqba8fd93137/0Dateien >0.txt, die gleichen Dateien.
Ganz klar niemals btrfs nehmen wenn man kein mitlaufendes backup(natürlich ein echtes keines das mitlöscht) hat. Also nur professionell zu gebrauchen. Ansonsten verzichtet man auf den Sicherheitsgewinn der checksummen und prüft ab und zu seine platten smart werte.
Sollte die Hardware einen Fehler haben fällt man eben für diese Datei auf sein Backup zurück. Bis das passiert hat man schon X und X mal mehr Dateien selber ausversehen gelöscht.
ich hatte seit 20 Jahren keine daten mehr verloren und konnte sonst immer alles wiederherstellen.
Ausser der trim bei opensuse KDE läuft für ext2 zu schnell, das weiß ich noch nicht.
Man löscht nicht immer in den Müll, zb. wenn man einen riesen Wust löschen muss den man im Mülleimer auch nicht überblicken könnte.
Und bei Stromausfall fehlen bei ext2 für eine Sekunde die Dateinamen aber nicht die Dateien selber, glaube ich zumindest. Aber was ist eine Sekunde zu Tagen oder Stunden die bei btrfs fehlen da man keine professionellen backups hat und die wiederherstellung müll ist.
btrfs ist für Normalnutzer klar schlechter als ext2, xfs scheint mir jetzt auch unheimlig und ext4 war schon immer und ist weiterhin Müll. Meine Smart werte sind top und ich hatte immer ext2. Einmal ein paar Wochen ext4 und schon Datenfehler. Und jetzt die enntäuschung mit btrfs, meine lust auf neue Dateisysteme ist mir vergangen.
Ausserdem kann man den “Trick” verwenden das opensuse mit btrfs laufen zu lassen und für home eine eigene ext2 Partition anzulegen. dann kann man weiterhin snap nutzen.
Nie was von „btrfs subvolume snapshot …” gehört?
Das ist dann ja eben nur bestenfalls ein stunden backup mit dem man daten verliert. Entweder hat man ein immer mitlaufendes Backup ohne Löschen, dann btrfs oder man nimmt zumindest für die home Partition ext2 und kann seine daten wiederherstellen, ext2 läuft zuverlässig und sogar knapp schneller als btrfs. Auf ext2 konnte ich bis jetzt immer alles wiederherstellen was ich blöderweise löschte. Allerdings teste ich noch wie scharf der trim in opensuse kde ist.
Also bericht nach 24 Std. mit ext2. Der computer lief jeweils den ganzen Tag, wenig schreibaufkommen halbe Platte leer. Wiederherstellung mit photorec, testdisk undelete konnte ich noch nie bei ext2 benutzen, dadurch fehlen natürlich die Dateinamen.
Das gelöschte odt und pdf konnten fehlerfrei gefunden werden, das jpg war nicht mehr vorhanden.
Bei btrfs fand ich 0 aktuelles, allerdings etwas das bereits 6 Tage alt war.
Nächste tests sind 3 Tage und 1 Woche. Vielleicht schont der trim ja gezielt textdateien?
Um auf alle Subvolumes eines btrfs zugreifen zu können muss es wie folgt gemountet werden:
**3400G:~ #** mount /dev/sdb2 -o subvolid=5 /mnt
**3400G:~ #**
Wird die Option subvolid=5 weggelassen mountet das Kommando den default subvolume:
**3400G:~ #** btrfs subvolume get-default /mnt/
ID 293 gen 6559 top level 264 path @/.snapshots/20/snapshot
**3400G:~ #**
Es kann dann ausschließlich auf diesen zugegriffen werden.
Möglicherweise habe ich ein zu einfaches Verständnis vom mount, aber ich hatte sdb2 überhaupt nicht gemountet da sonst die Wiederherstellung mit btrfs restore nicht funktioniert. Aber mit Option
subvolid=5 ist das wieder ganz was anderes?
Probieren geht über studieren. Vielleicht ist es der einfachste Weg, an die Daten zu kommen.
Leider weiterhin wertlos, nichts zu finden in den vielen snapshot verzeichnissen.
Ich weiss mittlerweile das ext2 wohl keinen trim bei unter ~64kb grossen dateien ausführt, bei grösseren scheinbar softort.
Das im Gedächnis macht man siene Bilder bei odt eben erst ganz zum schluss, schon müssten alle Schriften immer problemlos wiederherstellbar sein, was ja bei btrfs überhaupt nicht der fall ist.
Pdf aus Libreoffice erzeugt schaffen sogar sehr kleine Grafiken mit unter 64kb.
Für mich ist das völlig ausreichend und ein jpg abzusichern ist viel einfacher, da weiss man da ändert sich in zukunft nichts, was ja bei textdokumenten ganz anders ist.
Also weiterhin für “privat” auf jeden fall den home bereich mit zusätzlicher ext2 und btrfs nur für das system, sonst lieber alles mit ext2.
(btrfs könnte für das system wichtig sein, da es sofort daten schreibt, womit opensuse ja getestet wird. dh. theoretisch wären bei ext2 stabilitätsprobleme möglich indem das system bereits geschriebene werte erwartet, die bei ext2 eben nicht vorhanden wären. Für den home bereich natürlich niemals, da opensuse dort ja mit dem verhalten der diversen programme rechnen muss, die daten vielleicht erst nach minuten, ganz sicher aber nicht innerhalb 1 sek schreiben.)
Standardmäßig befindet sich /home in einem eigenen Subvolume und nicht in einem Snapshot.
Ob der Linux Kernel für das eingesetzte Speichermedium+Dateisystem TRIM unterstützt, erfährt man über den Befehl “lsblk”. => Details siehe unten verlinkten Archlinux-Artikel.
# lsblk --discard
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda 0 512B 2G 0
├─sda1 0 512B 2G 0
├─sda2 0 512B 2G 0
├─sda3 0 512B 2G 0
└─sda4 0 512B 2G 0
Alle Partitionen einer SSD sollten TRIM unterstützen. Wenn nicht, Dateisystem wechseln!
Wann TRIM durchgeführt wird, erfährt man hier im Detail:
https://wiki.archlinux.org/index.php/Solid_state_drive
Händisches TRIM erfolgt über:
# fstrim -va
/boot/efi: 290.8 MiB (304943104 bytes) trimmed on /dev/sda2
/home: 392.8 GiB (421784469504 bytes) trimmed on /dev/sda3
/: 5.9 GiB (6283038720 bytes) trimmed on /dev/sda1
Die mount-Option “discard” sollte nur als “discard=once” für SWAP-Partitionen verwendet werden:
# more /etc/fstab |grep -i discard
/dev/sda4 swap swap defaults,discard=once 0 0
Siehe dazu:
man swapon
Wie man testet, ob TRIM auch wirklich funktioniert, erfährt man in diesem Artikel:
https://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/Und ein Blick in diese Dateisystem-Übersicht von SUSE würde sich auch lohnen:
https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-filesystems.html