wie externen Datenspeicher mounten zum Lesen und Schreiben

B

bsdfreak

Well-Known Member
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:

Code: 
# /dev/rsd1c:
type: SCSI
disk: SCSI disk
label: Portable SSD   
duid: 0000000000000000
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]
  c:        488397168                0  unused                   
  i:        488329584             2048    NTFS                   
  j:            65536        488331632   MSDOS

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
 
Sieht danach aus. Ich kann es aber nicht mit Gewissheit beantworten, weil ich es nicht weiß. Meine Daten sind gerettet, das war mir wichtig.
 
Also, das die ssd mit exfat formatiert wurde von mir, ist sicher. Warum disklabel etwas anderes anzeigt, kann ich nicht sagen.
 
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.
 
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:

Code: 
fdisk -iy sd1
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:

Code: 
dd if=/dev/zero of=/dev/rsd1c bs=1m

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:

Code: 
disklabel -E sd1

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:

Code: 
newfs /dev/rsd1c

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

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

Code: 
/dev/sd1c /backup ffs rw 1 1

Rechner neu starten. Wenn alles erfolgreich war, ergibt

Code: 
disklabel sd1
# /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
Code: 
; dmesg
3. Gucken, was disklabel sagt
Code: 
; disklabel /dev/sd8c
; disklabel /dev/rsd8c
4. Mounten
Code: 
; mount -o rw /dev/sd8i /mnt/
(Alles als root)
Und hinterher umounten nicht vergessen.
Code: 
; umount /mnt/
 
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 ...

camcontrol(8)

man.freebsd.org man.freebsd.org

SSD Secure Erase – Thomas-Krenn-Wiki

In diesem Artikel zeigen wir wie Sie unter Linux ein Secure Erase einer SSD durchführen. Sie können damit die Performance vieler gebrauchten SSDs für die künftige Anwendung steigern. Es gehen dabei aber alle Daten der SSD verloren.
www.thomas-krenn.com www.thomas-krenn.com

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.
 
Zuletzt bearbeitet:
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....

NVMe-SSD sicher löschen / Secure Erase NVMe-SSD | SSDblog

www.ssdblog.de www.ssdblog.de
 
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.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben