'tar' direkt auf block device - Geht das ?

serie300

Well-Known Member
'n abend miteinander,

angeregt durch die Diskussion über Datensicherung in einem anderen Thread im Forum auf USB Stick , frage ich mich, ob man tar - anstatt auf einen Streamer - direkt auf einen USB Stick o. vergleichbar schreiben lassen kann. Also ohne File System und tar schreibt halt dann Block 1, Block 2, ... Ist das dann noch kompatibel, sodaß man später wieder mit einem anderen tar einlesen kann ? Das sollte ja schneller sein, wie mit einem File System. Also etwa so:
tar -c /dev/da2 /home
Muß man da noch was bei der Blocksize des Devices bedenken oder macht tar das dann automatisch?
Ein netter Nebennutzen wäre, daß man dann noch on-the-fly verschlüsseln kann und WinApfel Normal User erkennt auf dem Stick nichts (kein File System vorhanden).
Ja ich kann Google benutzen, aber finde fast nix zu tar im "raw" Modus. Streamer scheinen inzwischen außer in besonderen Bereichen außer Mode zu sein.
 
sodaß man später wieder mit einem anderen tar einlesen kann ?
Müsste im Prinzip gehen.

oder macht tar das dann automatisch?
tar macht da gar nix es schreibt einfach nur sequenziell die Daten. Muss es aber auch nicht, da das Blockdevice das ja von sich aus behandelt.

Ein netter Nebennutzen wäre, daß man dann noch on-the-fly verschlüsseln kann
Verschlüsselt könntest Du auch so. In dem Du den Output erst durch ein Crypt "pipst" und danach aufs Blockdevice.
So erzeugt man ja auch .tar.gz Datei. Da wird halt anschließend durch gzip "gepipt".
Oder meinst Du jetzt ein Encryption-Blockdevice-Layer?

(kein File System vorhanden).
Ja. Das stimmt wohl.

btw. Fileystem: osdev.org benutzt das TAR-Format als simples Dateisystem.
 
Ein netter Nebennutzen wäre, daß man dann noch on-the-fly verschlüsseln kann und WinApfel Normal User erkennt auf dem Stick nichts (kein File System vorhanden).

Naja, das hat man zumindest unter win auch wenn man nen ffs oder ext4 direkt aufs device schreibt, das sollte auch gehen ;)

Tar gibts allerdings auch für Windows, interessante wenn auch etwas absurde idee um Daten Systemübergreifend auszutauschen überlege ich gerade.
 
Ich dachte eigentlich daran das tar interne Verschlüsselungskommando zu verwenden, aber mit -O auf eine Pipe wie von Andy_m4 vorgeschlagen ist auch eine interessante Idee.

Zu CommanderZed: Bei großen Datenvolumen >32GB, die dann proprietäre / nicht-freie Dateisysteme (exFAT, ...) brauchen 'ne Idee.
 
Ich dachte eigentlich daran das tar interne Verschlüsselungskommando zu verwenden, aber mit -O auf eine Pipe wie von Andy_m4 vorgeschlagen ist auch eine interessante Idee.

Zu CommanderZed: Bei großen Datenvolumen >32GB, die dann proprietäre / nicht-freie Dateisysteme (exFAT, ...) brauchen 'ne Idee.
Gibt ja auch nen paar grenzen bei fat (verschachtelung, sonderzeichenkrams der in tar normalerweise gelöst ist oder aber zumindest erst viel später auftritt) - fat ist ein arschloch
 
Das sollte ja schneller sein, wie mit einem File System.
Das ist schneller (dennoch macht man bei 512b-Platten einen 4096b Layer drüber*, damit man das Optimum rausholt), aber bei einem lahmen Stick macht sich das beides nicht bemerkbar...das Problem ist, dass meistens die Chips aus Holz sind und das deswegen einfach ablahmt. Das würde es auch, wenn sie einen Cache vorwiesen.

*Du könntest auch den Stick direkt mit geli verschlüsseln (und 4k testen) und dann aufs *.eli dein tar drücken lassen.
geli init -b -l 256 -s 4096 /dev/daX

Da könnte dann auch das Thema write amplification (wenn du nur 512b schreibst, muss der Stick trotzdem seine 4096b schreiben) zum Nachschlagen anregen, aber bei den Preisen eines Sticks eher semi-relevant.
 
Man könnte auch files direkt drauf schreiben, mit dd z.B., man muss sich natürlich recht genau merken wo man die hinschreibst, aber dann spart man sich das ganze tar gehampel

/edit Villeicht macht man sich auch ne kleine Tabelle und schreibt die immer gleich am anfang, wo welche Datei anfängt / aufhört etc, da reicht ja auch ne Textdatei!
 
Vielleicht hilfreich ist, dass FreeBSD tar-Archive als read-only Dateisystem mounten kann: mount -t tarfs /pfad/zum/arch.tar /mnt
 
Um mal tar(1) (OpenBSD) zu zitieren:
Code:
A tar archive is often stored
     on a magnetic tape, but can be stored equally well on a floppy,
     CD-ROM, or in a regular disk file.

/edit Villeicht macht man sich auch ne kleine Tabelle und schreibt die immer gleich am anfang, wo welche Datei anfängt / aufhört etc, da reicht ja auch ne Textdatei!
Also eine Tabelle mit den File Allocations? Witzige Idee! :)
 
Stichwort "crypten"...

ODER man nimmt gleich openssl.


encrypten
Code:
; echo "This is my password!" >keyfile.txt
; tar cvf - /whatever | openssl aes-256-cbc -salt -pbkdf2 -pass file:keyfile.txt | dd of=/dev/rsdXc bs=1M
; rm -P keyfile.txt

decrypten
Code:
; echo "This is my password!" >keyfile.txt
; dd if=/dev/rsdXc bs=1M |  openssl aes-256-cbc -d -pbkdf2 -pass file:keyfile.txt | tar xvf -
; rm -P keyfile.txt
 
Code:
; rm -P keyfile.txt
Anmerkung der Redaktion: Die Option -P bringt nur auf OpenBSD etwas. FreeBSD sagt:

FreeBSD RM(1) schrieb:
-P This flag has no effect. It is kept only for backwards
compatibility with 4.4BSD-Lite2.

und der Vollständigkeit wegen:

OpenBSD rm(1) schrieb:
-P Attempt to overwrite regular writable files before deleting them. Files are overwritten once with a random pattern. Files with multiple links will be unlinked but not overwritten.
 
nur noch als Bestätigung aus eigener Erfahrung: eines der Geräte in unserer Firma (mit einer Sparc drinnen und sehr lange her) machte das auf Disketten.
Erstaunlich genug, dass in unserer Firma das vermeintliche Wissen kursierte, dass diese Daten unlesbar seien. Schon durch diese Aussage angespornt habe ich sie dann eben trotzdem ausgelesen und es war nichts verschlüsselt und nichts binär, alles reine Text-Dateien in einem TAR.
Ich meine, wenn selbst unsere Speziallisten das für unlesbar hielten, ist die Chance groß, dass der 0815-User nicht auf die Idee kommt, das Medium genau zu betrachten.

Was die Verschlüsselung selbst angeht, stehe ich damit ja immer noch ein wenig auf Kriegsfuß und möchte nur anmerken, dass dann, wenn der Datenträger auch auf anderen Systemen gelesen werden soll, es afaik keine wirklich gescheite (Datenträger-)Verschlüsselung gibt, die von allen Systemen beherrscht wird. Nun, wenn man aber eine Datei (ein TAR) eh verschlüsselt, wo ist dann der Unterschied dazu, wenn ich es auf ein Dateisystem lege oder es ohne dieses direkt auf den Datenträger schreibe?
 
nur noch als Bestätigung aus eigener Erfahrung: eines der Geräte in unserer Firma (mit einer Sparc drinnen und sehr lange her) machte das auf Disketten.
Erstaunlich genug, dass in unserer Firma das vermeintliche Wissen kursierte, dass diese Daten unlesbar seien. Schon durch diese Aussage angespornt habe ich sie dann eben trotzdem ausgelesen und es war nichts verschlüsselt und nichts binär, alles reine Text-Dateien in einem TAR.
Ich meine, wenn selbst unsere Speziallisten das für unlesbar hielten, ist die Chance groß, dass der 0815-User nicht auf die Idee kommt, das Medium genau zu betrachten.

Was die Verschlüsselung selbst angeht, stehe ich damit ja immer noch ein wenig auf Kriegsfuß und möchte nur anmerken, dass dann, wenn der Datenträger auch auf anderen Systemen gelesen werden soll, es afaik keine wirklich gescheite (Datenträger-)Verschlüsselung gibt, die von allen Systemen beherrscht wird. Nun, wenn man aber eine Datei (ein TAR) eh verschlüsselt, wo ist dann der Unterschied dazu, wenn ich es auf ein Dateisystem lege oder es ohne dieses direkt auf den Datenträger schreibe?

Bei "alle Betriebsysteme" wirds wirklich schwierig, selbst wenn man dann nur die gängigen* meint.

Linux kann glaub ich inzwischen Microsofts Bitlocker, das wäre dazwischen eine Option, lässt aber natürlich *BSD, MacOS und die Mobiles raus.

Ein verschlüsseltes Archiv zu verwenden (Natürlich nicht wie hier vorgeschlagen direkt aufs Block-Device, Android-Apps können glaub ich garnicht so tief zugreifen) erscheint mir da tatsächlich eine praxisnahe und oft gelebte Lösung, das 7zip native Format soll inzwischen recht sicher sein glaub ich und ist auf allen Plattformen leicht verfügbar, afaik auch unter Android und iOS / MacOS.

Deshalb sind diverse Sharetools wie klassische Fileshares, Nextcloud, Syncthing natürlich auch interessant: Wenn der Server, Transportweg und Endgerät an sich verschlüsselt ist, kann man sehr Anwenderfreundlich sich recht sicher sein das nicht jeder die Daten lesen kann.

*Gängig Außerhalb dieses Forums: Windows, MacOS, Android, iOS, iPad OS, Linux
*Gängig innerhalb dieses Forums: s.o. plus *BSD
 
Was die Verschlüsselung selbst angeht, stehe ich damit ja immer noch ein wenig auf Kriegsfuß und möchte nur anmerken, dass dann, wenn der Datenträger auch auf anderen Systemen gelesen werden soll, es afaik keine wirklich gescheite (Datenträger-)Verschlüsselung gibt, die von allen Systemen beherrscht wird.
Das Problem selbst hast du bereits mit Dateisystemen, ich wüsste da für max. Kompatibilität auch nichts außer exFAT, aber gescheit ist das nicht, es ist nur funktional.
Man kann mit dem Stick auch einen ZFSpool nativ (oder auch nur ein dataset) verschlüsselt anlegen (immer brav an export/import denken ;) ), FreeBSD und Linuxe können das, Win/Mac wahrscheinlich auch mittels Addon irgendwie könnte ich mir vorstellen.

7zip (-mhe=on -pPaSsWoRt) nutze ich auch ganz gerne auf Dateiebene. Der Nachteil dabei ist, dass man temporär den doppelten Speicherplatz braucht.
 
Nun, wenn man aber eine Datei (ein TAR) eh verschlüsselt, wo ist dann der Unterschied dazu, wenn ich es auf ein Dateisystem lege oder es ohne dieses direkt auf den Datenträger schreibe?
Man spart sich die bytes, die das Dateisystem selber verbraucht.

Edit: und natuerlich ueberhaupt erst den Aufwand etwas zu "mounten" - oder Formate verstehen zu muessen.
Solange das OS sowas wie "block" kann (und es ein tar verstehendes Programm), kann man los legen.
 
Zurück
Oben