wie externen Datenspeicher mounten zum Lesen und Schreiben

Ich habe noch ein externes Backup Device, das an USB 3.1 angeschlossen ist. Ich möchte es weiter verwenden, aber zuerst die Daten auf meine erste SSD sichern, um dann später das Backup Device mit UFS neu zu formatieren.

disklabel sd1 ergibt:


Wie kann ich die mounten, damit ich auf meine Daten zugreifen kann? Muß ein extra Treiber für NTFS installiert werden? Und geht das unter OpenBSD denn überhaupt.

Soweit ich weiß, hat OpenBSD readonly unterstützung für NTFS - sollte für dich ja ausreichen. Also wäre es wohl sowas wie: mount_ntfs /dev/rsd1i /mnt

Meine OpenBSD Kentnisse sind allerdings bescheiden.

medV2 schrieb:

Soweit ich weiß, hat OpenBSD readonly unterstützung für NTFS - sollte für dich ja ausreichen. Also wäre es wohl sowas wie: mount_ntfs /dev/rsd1i /mnt

Zum Vergrößern anklicken....

Nicht ganz. Du versuchst das (r)aw-device (r)sd1i zu mounten. Wenn, dann ohne das r.

bsdfreak schrieb:

Wie kann ich die mounten, damit ich auf meine Daten zugreifen kann? Muß ein extra Treiber für NTFS installiert werden? Und geht das unter OpenBSD denn überhaupt.

Zum Vergrößern anklicken....

Evtl. hilft dir das auch weiter: https://www.tumfatig.net/2024/mounting-ntfs-and-exfat-filesystems-on-openbsd/

Ansonsten die ueblichen Quellen: https://man.openbsd.org/mount_ntfs

Also dies hat funktioniert:

bsdfreak schrieb:

Also dies hat funktioniert

Zum Vergrößern anklicken....

Das hieße ja dann, in der Partitionstabelle war der falsche fstype hinterlegt?!

Sieht danach aus. Ich kann es aber nicht mit Gewissheit beantworten, weil ich es nicht weiß. Meine Daten sind gerettet, das war mir wichtig.

Rein technisch kann man da irgendwas reinschreiben, das ist fuer das spaeter genutzte Filesystem unerheblich.

Also, das die ssd mit exfat formatiert wurde von mir, ist sicher. Warum disklabel etwas anderes anzeigt, kann ich nicht sagen.

double-p schrieb:

Rein technisch kann man da irgendwas reinschreiben

Zum Vergrößern anklicken....

Das ist klar. Wäre nur mal interessant zu wissen, wie es dazu kam oder ob hier disklabel auch einfach nur was falsch ausgelesen hat oder was auch immer.
Ist jetzt auch nicht super wichtig. Hab nur interessehalber nachgefragt.

du siehst den letzten Bereich auch als MSDOS gelabeled.
Wollen wir wetten, ob das so stimmt?
Nur mein Bauchgefühl, kein bisschen Wissen: diese "altmodischen" Dinger wie disklabel oder fdisk und so, zeigen nicht wirklich gut, was Sache ist.
Besser ist unser (FreeBSD) gpart oder das mmls aus dem Sleuthkit oder die Ausgabe von file -s auf das Dateisystem / die Partition. Ich verlasse mich deshalb nicht gerne auf die Ausgabe eines einzigen Programms.
Zumal, wie oben gesagt, Label ja auch nur Label sind und ich kann auch ganz verwegene und krumme Kombinationen machen. War das mal ein NTFS? wurde dann nur neu formatiert? Hatte die Formatier-SW keinen passenden Label für X-Fat? und so weiter. Im Zeitalter der Automatisierung solcher Vorgänge interessiert sich doch niemand mehr, wie etwas funktioniert.

pit234a schrieb:

du siehst den letzten Bereich auch als MSDOS gelabeled.

Zum Vergrößern anklicken....

Das ist ganz klar die EFI-Partition. :-)

Und ja. file -s ... kann natürlich helfen. Oder man geht einfach mit mount alle Dateisysteme durch und guckt, wo der Exitcode 0 ist. :-)

Andy_m4 schrieb:

Oder man geht einfach mit mount alle Dateisysteme durch und guckt, wo der Exitcode 0 ist. :-)

Zum Vergrößern anklicken....

aus der Hüfte, kann nicht anders:
an solchen Antworten merkt man doch immer wieder, dass du mit IT Geld verdienst ;-)

So, nachdem meine Datenrettung erfolgreich war, stellt sich mir noch die Aufgabe, die SSD komplett mit allen Partitionen zu löschen und neu mit dem OpenBSD Filesystem zu formatieren:

Zuerst löschen wir das Partitionsschema:

Festplatte überschreiben (optional, für Sicherheit)
Das -i-Flag initialisiert das Laufwerk.
Das -y-Flag bestätigt automatisch die Rückfrage.

Jetzt überschreibe ich die SSD (optional, für Sicherheit)
Falls wir die SSD aus Sicherheitsgründen überschreiben möchten, können wir dies mit dd tun. Dieser Schritt ist notwendig, wenn wir sicherstellen möchten, dass alte Daten nicht wiederherstellbar sind:


if=/dev/zero: Füllt die gesamte SSD mit Nullen.
of=/dev/rsd1c: Schreibt auf die rohe (unpartitionierte) Festplatte.
bs=1m: Verwendet 1-MB-Blöcke, um den Vorgang zu beschleunigen.

Disklabel zurücksetzen

Nach dem Löschen des Inhalts sollte auch das Disklabel entfernt werden:


Gib in der Disklabel-Shell den Befehl z ein, um die Partitionen zu löschen. Anschließend verlasse die Disklabel-Shell mit q.

Jetzt wird neu gelabelt und anschließend neu formatiert:


Dann habe ich einen Mountordner backup erstellt und den mit Schreib/Leserechten versehen.

Und folgenden Eintrag zur /etc/fstab hinzugefügt:


Rechner neu starten. Wenn alles erfolgreich war, ergibt

# /dev/rsd1c:
type: SCSI
disk: SCSI disk
label: Portable SSD
duid: e87b1f5586a13423
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 30401
total sectors: 488397168
boundstart: 0
boundend: 488397168

16 partitions:
# size offset fstype [fsize bsize cpg]
a: 488397120 0 4.2BSD 4096 32768 1
c: 488397168 0 4.2BSD 2048 16384 12960 # /backup

Das wars. Hab es mal dokumentiert, wenn jemand auch vor solch einer Aufgabe steht.

Der Vollständigkeit halber: Das Nullen kann man sich bei SSDs (je nach Bedrohungsszenario) eigentlich sparen, ein TRIM ist da ganau so ausreichend. Zumindest mit Softwaretools kannst du da nix mehr herstellen. Ob die NSA im Labor etwas rekonstruieren kann ist natürlich ne andere Sache. Aber wenn das meine Sorge ist, würde ich mindestens den DoD Standard vewenden (srm -D)

du hast damit, wenn ich das alles richtig verfolgt habe, ein externes Dateisystem über die fstab eingebunden.

Unabhängig von OpenBSD kann so etwas unter Umständen eine schlechte Idee sein oder anders ausgedrückt, man sollte sich voll bewusst sein, welche Nachteile man sich damit eventuell einhandeln kann. Zum Beispiel wird erwartet, dass das Gerät nun immer beim Booten (mit sauberem Dateisystem) vorhanden ist (und zwar immer "am gleichen Platz", weil dein fstab-Eintrag auf das Gerät und nicht einen Label geht) und es wird erwartet, dass es nicht irgendwann während der Laufzeit mal verschwindet (weil zB ein Suspend erfolgt, der die Spannung vom USB nimmt und wodurch eine angeschlossene Festplatte erst "später" erwacht und wieder bereit ist, als das Restsystem).
Der Hinweis "am gleichen Platz", bezieht sich dabei nicht auf den benutzten USB-Port, sondern auf die Zuweisung des Dateisystems auf /dev/sd1c. Hast du mal ein anderes Gerät beim Booten eingesteckt, das die Bedingungen erfüllt, würde dieses auf /backup eingebunden.

Nur noch kurz der Hinweis, dass grundsätzlich die Platte nicht hätte nach UFS umformatiert werden, um auf diese Weise gemountet werden zu können.

Ich mache das immer in mehreren Schritten:
1. Einstecken
2. Gucken, welches device das ist
3. Gucken, was disklabel sagt
4. Mounten
(Alles als root)
Und hinterher umounten nicht vergessen.

medV2 schrieb:

Das Nullen kann man sich bei SSDs (je nach Bedrohungsszenario) eigentlich sparen

Zum Vergrößern anklicken....

Kann man nicht nur, man sollte. Weil das einfach unnötig Haltbarkeit aus der SSD abschabt.

SATA SSDs (und vereinzelt HDDs):
camcontrol security ...

NVMe (via paket nvme-cli):
nvme sanitize -a2 /dev/nvme0 (block erase, schnell)
nvme sanitize -a4 /dev/nvme0 (secure erase, neuer key, schnell)

bsdfreak schrieb:

bs=1m: Verwendet 1-MB-Blöcke, um den Vorgang zu beschleunigen.

Zum Vergrößern anklicken....

Der optimalste Optimalwert als Optimum wäre die Cachegröße, den die Platte/SSD jeweils hat.

medV2 schrieb:

Das Nullen kann man sich bei SSDs (je nach Bedrohungsszenario) eigentlich sparen, ein TRIM ist da ganau so ausreichend.

Zum Vergrößern anklicken....

Als kleine Anmerkung/Ergänzung:
Vor allem ist ja insbesondere bei SSD nicht unbedingt sichergestellt, wann die Daten tatsächlich gelöscht sind und ob nicht noch irgendwas in Reserveblöcken steckt.
Eigentlich hat man ja genau deshalb dafür Secure-Erase, welches leider nicht durch USB durch geht (EDIT: bzw. unerwünschte Nebenwirkungen haben kann, da die Prozedur nicht abbrechen darf; weitere Ergänzung siehe #19).

pit234a schrieb:

fstab

Zum Vergrößern anklicken....

Mal so als Idee:
Alternativ könnte man natürlich mit hotplugd herumexperimentieren.

Andy_m4 schrieb:

wann die Daten tatsächlich gelöscht sind und ob nicht noch irgendwas in Reserveblöcken steckt.
Eigentlich hat man ja genau deshalb dafür Secure-Erase, welches leider nicht durch USB durch geht.

Zum Vergrößern anklicken....

Bei NVMEs ist das zum Glück besser:

The big difference between Sanitize and Format is that sanitize ensures caches are deleted, and the process starts again after an unexpected power loss. Sanitize also supports a pattern overwrite for a secure erase operation, which is terrible for NAND endurance but can be used with other types of storage and memory classes, or for more certainty that user data cannot be recovered.

Zum Vergrößern anklicken....

mr44er schrieb:

Kann man nicht nur, man sollte. Weil das einfach unnötig Haltbarkeit aus der SSD abschabt.

Zum Vergrößern anklicken....

gerade bei (den wenigen) externen SSDs, habe ich das trotzdem gemacht, aber hauptsächlich in der vielleicht irrigen Annahme, dass sich hierbei Probleme womöglich durch Performance-Einbrüche bemerkbar machen oder sich doch irgendwie auf smartcontrol durchschlagen würden.
Das Formtieren geschieht ja heute nur noch "an der Oberfläche". Ihr wisst, was ich meine, mir fehlen grad die richtigen Worte.

Ich mag ja was verpasst haben.. aber mit so einem dd kann man sich das fdisk/disklabel loeschen sparen (eh schon weg).
Um die Disk unter OpenBSD data-only zu verwenden, braucht es kein MBR/fdisk gedoens - ein disklabel reicht.

Zur fstab: noauto - dann stoert eine fehlende Platte/slice beim booten nicht, und man kann trotzdem ein schlichtes "mount /backup" machen.

double-p schrieb:

Zur fstab

Zum Vergrößern anklicken....

kennt OpenBSD nicht auch die Möglichkeit, Dateisysteme / Partitionen zu labeln?
Ich erinnere mich finster an Zeiten, wo ich in FreeBSD noch UFS nutzte und da gibt es /sbin/glabel, was man dafür (glaube ich) benutzen konnte. Damit werden solche Einträge in der fstab dann viel flexibler, weil sie das Dateisystem auch an "anderen Plätzen" (siehe oben) zuverlässig erkennen.

Man kann dem disklabel eine disk UID geben, die slices bleiben a-z, also man hat dann zB 3eb7f9da875cb9ee.a.
Dass man das kann, steht direkt in der fstab manpage (fs_spec).

Dem OpenBSD filesystem selber kann man kein label verpassen.

Das mag unpraktischer sein, man sollte aber auch ueberlegen, dass hinz+kunz solche labels auf externe datentraeger
schreiben kann und dann hat man auch mal ein flexibles Problem..

Gibts unter openBSD keine "nofail" Option für die fstab? Dann würde das Ding ganz normal gemountet werden, wenn vorhanden, und sonst eben nicht, ohne, dass es beim booten stören würde.

echo "mount /backup 2>/dev/null" >> /etc/rc.local (mit dem schon beschriebenem noauto).