IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: Storage (Seite 2 von 2)

ZFS: Warum dieses Dateisystem anders ist

ZFS ist kein normales Dateisystem — es vereint Dateisystem, Volumemanager und RAID in einem. Keine separate Partitionierung, kein mdadm, kein LVM. Ein Befehl erstellt einen Pool, ein zweiter ein Dataset. Snapshots, Compression, Verschlüsselung und Replikation sind eingebaut. Ursprünglich von Sun Microsystems für Solaris entwickelt, läuft ZFS heute als OpenZFS auf FreeBSD, Linux und macOS.

Was ZFS anders macht

Copy-on-Write: Daten werden nie überschrieben — jede Änderung wird an eine neue Stelle geschrieben. Erst wenn der neue Block vollständig ist, wird der Zeiger umgehängt. Dadurch gibt es kein Write Hole wie bei klassischem RAID und Snapshots sind praktisch kostenlos.

Checksummen und Selbstheilung: Jeder Block hat eine Checksumme, gespeichert im übergeordneten Block (Merkle Tree). Beim Lesen wird die Checksumme geprüft — bei einem Fehler repariert ZFS den Block automatisch aus der Redundanz. Silent Data Corruption wird erkannt, bevor sie Schaden anrichtet.

Integrierter Volumemanager: ZFS weiß, welche Blöcke belegt sind und welche nicht. Beim Resilvering (Neusynchronisation nach Plattenausfall) werden nur belegte Blöcke kopiert — ein 80-GB-Mirror mit 4 GB Daten ist in Minuten fertig statt Stunden.

Technische Eckdaten

Adressierung128 Bit
Max. Dateisystemgröße16 EiB (16 × 2⁶⁰ Byte)
Max. Poolgröße256 ZiB (256 × 2⁷⁰ Byte)
Max. Dateien pro Verzeichnis2⁴⁸
Max. Geräte pro Pool2⁶⁴
RAID-LevelMirror, RAID-Z (1–3 Paritäten), Striping, Spare
VolumemanagerIntegriert

ZFS im Detail — die Artikelserie

Jedes Feature ist in einem eigenen Beitrag erklärt:

Fragen? Einfach melden.

Solaris gpodder

Veraltet: OpenIndiana und Solaris werden kaum noch produktiv eingesetzt. gpodder läuft problemlos unter Linux und FreeBSD.

gPodder Solaris Openindiana Opensolaris MTPDer OpenSolaris fork Openindiana und gPodder

Ich nutze zur Verwaltung meiner abonnierten Podcasts schon seit langer Zeit gPodder. Es ist schlank klein, schnell und tut nur das was ich möchte Das soll unter Openindiana nun auch so sein. Zusätzlich möchte ich auch gerne die Podcasts auf meinen Creative ZEN mozaic per MTP schieben. Hier gibt es zwar ein kleines Problem, dieses konnte ich aber für mich mit einem (ganz ganz ganz ganz bösen) Workaround lösen, davon später mehr.

Um gpodder auf mein System zu bekommen sind zusätzlich noch folgende Python Erweiterungen nötig:

– feedparser (http://code.google.com/p/feedparser/downloads/list)
– mygpoclient (http://thp.io/2010/mygpoclient/)

Einfach herunterladen, auspacken:

$ gzcat feedparser-5.0.1.tar.gz | tar xvf -
$ gzcat mygpoclient-1.6.tar.gz | tar xvf -

Und dann ganz schnell als root installieren:

$ cd feedparser
$ python setup.py build
$ python setup.py install
$ cd ..
$ cd mygpoclien
$ python setup.py build
$ python setup.py install

Man man man…. Das ging ja noch. Jetzt also gpodder (http://gpodder.org/downloads.html). Nach dem Download entpacken und dann…

$ gzcat gpodder-2.19.tar.gz | tar xvf -
$ cd gpodder
$ python setup.py build

Immer wenn ich nun ein python setup.py install gestartet habe blieb er mit folgender Meldung hängen:

error: can't copy 'data/org.gpodder.service': doesn't exist or not a regular file

Ganz braun hat mir hie folgendes geholfen:

$ cd data
$ cp org.gpodder.service.in org.gpodder.service
$ cd ..
$ org.gpodder.service

Damit lässt sich gpodder auch schon starten und benutzen. Mir fehlt nur noch die Unterstützung von MTP (http://libmtp.sourceforge.net/) nach Download und Auspacken kommt der bekannte Dreisatz zum Tragen:

$ ./configure
$ make
$ make install

Fertig…

Fertig? Na ja fast!

$ mtp-detect

erkennt meinen Player. mtp-files listet die auf dem Player befindlichen Files auf und ein mtp-sendfile schiebt eine mp3 Datei sauber und abspielbar auf den MP3-Player. Wenn ich nun im gpodder unter: Preferences ==> Devices ==> Device type: MTP einstelle. Kann ich mit der rechten Maustaste Podcasts an meinen MP3-Player senden. Diese kommen dort wirklich an und sind in der Liste auswählbar. Ich bekomme nur im MP3-Player die Meldung: „Problem bei der Audiowiedergabe“ das File wieder übersprungen und Ende. So habe ich mir das nicht vorgestellt :-/ Vor allem lassen sich Dateien abspielen, welche ich von Hand auf der Konsole per mtp-sendfile herüberschiebe. Daher müsste es doch auch über den gpodder funktionieren, oder?

Beim Auflisten der Files vom MP3-Player ist mir aber etwas spannendes aufgefallen:

$ mtp-files

File ID: 18655
Filename: 1LIVE - Comedy_ Dennis ruft an_ ANUGA (10.10.2011).mp3
File size 964156 (0x00000000000EB63C) bytes
Parent ID: 96
Storage ID: 0x00010001
Filetype: RIFF WAVE file

File ID: 8214
Filename: pofacs#093 - Commodores Homecomputer.mp3
File size 98408576 (0x0000000005DD9880) bytes
Parent ID: 96
Storage ID: 0x00010001
Filetype: ISO MPEG-1 Audio Layer 3

AHA… Der funktionsfähige, von Hand angeschobene, Podcast hat den Filetype: ISO MPEG-1 Audio Layer 3

Dieses ist für ein MP3-File auffallend korrekt. Der vom gpodder hochgeschobene Podcast hat den Filetype: RIFF WAVE file. Das kann ja nicht klappen.

Ich tippe nun mal dass es irgendwo im gpodder auf meiner Solaris Kiste ein Problem damit gibt den Filetype richtig zu erkennen oder zu setzten (Vermutung halt)… Ich habe den Quelltext nun einmal hoch und runter gescrollt aber nichts gefunden (ich bin halt kein Programmierer)…. Ich habe nur eine Liste von Filetypen gefunden mit dem Hinweiss das diese immer syncron mit den Einträgen aus der libmtp.h sein müssen.

Daher habe ich mir mal die libtmp.h.in angeschaut. Hier finden sich diese Filetypen wieder. Was soll ich sagen? An erster Stelle steht jeweils WAV… Nun zu meinem bösen Versuch (bitte nicht schimpfen) ich habe einfach den ersten Eintrag:

LIBMTP_FILETYPE_WAV,

ausgetauscht gegen:

LIBMTP_FILETYPE_MP3,

Weiter unten habe ich dann MP3 gegen WAV getauscht. Nun einfach libmtp neu übersetzen und, ja es funktioniert. Zumindest mit MP3 Files.

Bei Zeiten müsste ich mich hier wohl mal eingehender beschäftigen oder mal einen Bug aufmachen, das Problem könnte auch hausgemacht sein. Bei Zeiten…..

USB-Surfstick O2 ZTE MF190 und Gentoo

Ich bin nur sehr selten an einem Ort, an welchem ich keine Internetverbindung nutzen kann. Noch seltener würde ich genau dann eine Internetverbindung benötigen. Wenn es dann aber so ist, dann benötige ich sie wirklich!

Nun komme ich in der letzten Zeit immer mal wieder an diese Stelle und ärgere mich. Oft ist zwar ein Kollege oder Bekannter in der Nähe, mit so einem feinen Android Mobiltelefon, nur hilft mir dieses beim Arbeiten auf einer SSH-Shell weniger. Ja, es geht aber wirkliches Arbeiten geht nicht… Zudem bin ich ein Mensch der seinen Windowmanager benutzt, sprich viele offene Fenster. Auf so einem kleinen Mobilding ist mir mehr als eine kurze E-Mail oder etwas Google klicker klacker einfach zu aufwändig.

Das Handy also als Modem mit dem Rechner verbinden? So selten wie ich es im Moment benötige, mich direkt 1 Jahr an einen 20€/Monat Tarif meines Anbieters zu binden? Ne, so geht das nicht….

Vor kurzem war ich nun im Blödmarkt unterwegs. Da lagen in der Grabbelkiste so 15 Euronen O2 Prepaid USB-Sticks.

Dem etwas überforderten Fachberater für die Dinger konnte ich mit etwas Mühe die Information entlocken, dass ich über dieses Angebot „echtes“ Internet erhalte. Damit ist gemeint, dass ich SSH-Sessions auf beliebigen Ports öffnen kann und auch mein IPv6 Tunnelbroker funktionieren sollte. ….Nebenbei, habt ihr im Blödmarkt mal gefragt ob ihr über was auch immer eine Verbindung zu einen IPv6 Tunnelbroker aufbauen könnt? Macht mal, ist lustig.

HTTP / SMTP / IMAP mit und ohne SSL/TLS alles kein Problem!

Mit der 5 Tage x 3,50€ = 17,50€ Sollte einem Test nichts im Wege stehen. Keine Grundgebühr oder sonstige laufenden Kosten… Ich brauche es nicht, ich zahle es nicht. Wenn ich also feststelle das ich es doch oft und gut nutze, so dass sich einer der Knebelverträge des Anbieters meines Vertrauens lohnen würde, dann kann ich das Teil wegwerfen und mich bewusst knebeln lassen. Anderweitig habe ich eine tolle Lösung für den Notfall!

Beim Kauf habe ich jetzt nicht darauf geachtet ob das Teil nun unter bzw. mit meinem Linux (Gentoo) zusammenarbeitet. Den Fachberater im Blödmarkt wollte ich es nun nicht noch fragen, er schien jetzt schon von mir genervt zu sein!

Hey, gut wie ich bin, bekomme ich das Teil schon zum rennen (Boar ist diese Selbstüberschätzung nicht wiederlich?)!

Da meine Frau etwas von: „Rausgeworfenes Geld…. Überflüssiges Spielzeug… und du sitzt eh viel zu viel vor dem Computer!“ murmelte…. _MUSS_ das Teil einfach Laufen.

Tut es nur so ~out of the box~ nicht! Dass hat man nun also davon, man kauft im Blödmarkt halt nichts. Vor allem nicht ohne Verstand, oder gerade deswegen? Wie auch immer, so haben ich es ans Laufen bekommen!

Ich habe hier also den O2 Surfstick MF190 von der Firma ZTE.

O2 ZTE MF190 HSUPA Stick

Stecke ich diesen einfach in mein System ein und schaue mir an was der Kernel dazu sagt, sehe ich folgendes:

$ dmesg
usb 2-1: new high speed USB device using ehci_hcd and address 3
usb 2-1: New USB device found, idVendor=19d2, idProduct=0083
usb 2-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4
usb 2-1: Product: ZTE WCDMA Technologies MSM
usb 2-1: Manufacturer: ZTE,Incorporated
usb 2-1: SerialNumber: P671A2TMED010000
scsi7 : usb-storage 2-1:1.0
scsi 7:0:0:0: CD-ROM            ZTE      USB SCSI CD-ROM  2.31 PQ: 0 ANSI: 2
sr1: scsi-1 drive
sr 7:0:0:0: Attached scsi CD-ROM sr1
sr 7:0:0:0: Attached scsi generic sg2 type 5

Der Stick wird also als USB-CDROM Laufwerk (hier liegt die Software für die Windows User) und USB-Festplatte (sofern eine MicroSD-Karte eingelegt ist, wäre es diese) erkannt.

Mal schauen was ein lsusb sagt:

$ lsusb
Bus 002 Device 004: ID 19d2:0083 ONDA Communication S.p.A

19d2 steht für den Hersteller und 0083 für das Gerät selbst. Google sagt 0083 ist der Stick aber im Modus (ich nenne es mal) Datenlaufwerk. Ich will aber Modem 🙂 Hierzu sagt Google man muss ein paar bestimmte Kommandos schicken und schon wechselt der USB-Stick seinen Modus. Findige Leute haben sich da schon einen Kopf zu gemacht und das Programm: usb_modeswitch geschrieben. Also soll emerge mal loslegen:

$ emerge usb_modeswitch

Solange er rechnet könnte ich meinen Kernel ja schon mal davon überzeugen das Gerät zu „ignorieren“. Dazu füge ich in die Datei: /usr/src/linux/drivers/usb/storage/unusual_devs.h folgende Zeilen ein:

UNUSUAL_DEV(  0x19d2, 0x0117, 0x0000, 0x0000,
"ZTE Sinnlos",
"USB UMTS Sinnlos",
US_SC_DEVICE, US_PR_DEVICE, NULL,
US_FL_IGNORE_DEVICE),

Damit Geräte dieser Art überhaupt funktionieren können (und ich nach der Änderung in unusual_devs.h ja eh neu kompilieren muss) sollte die Kernelkonfiguration wie folgt angepasst werden:

Device Drivers ->
USB support  --->
<M> OHCI HCD support (If not use Intel or VIA chipset)
<M> UHCI HCD (most Intel and VIA) support (If use Intel or VIA chipset)
<M> USB Serial Converter support  --->
[*] USB Generic Serial Driver
<M> USB driver for GSM and CDMA modems
Network device support  --->
<*> PPP (point-to-point protocol) support
<*> PPP support for async serial ports

Inzwischen ist usb_modeswitch fertig. Für meinen Stick muss ich leider noch etwas Handarbeit leisten. Denn in der Datei /lib/udev/rules.d/40-usb_modeswitch.rules müssen noch folgende Zeilen hinzugefügt werden:

# ZTE MF190 (Variant)
ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="0117", RUN+="usb_modeswitch '%b/%k'"

Damit die neue Regel zur Anwendung kommen noch schnell ein:

$ udevadm control --reload-rules

Jetzt sollte es beim Einstecken vom Stick schon anders aussehen….

$ dmesg
usb 2-1: new high speed USB device using ehci_hcd and address 4
usb 2-1: New USB device found, idVendor=19d2, idProduct=0117
usb 2-1: New USB device strings: Mfr=3, Product=2, SerialNumber=4
usb 2-1: Product: ZTE WCDMA Technologies MSM
usb 2-1: Manufacturer: ZTE,Incorporated
usb 2-1: SerialNumber: P671A2TMED010000
usb-storage 2-1:1.0: device ignored
usb-storage 2-1:1.1: device ignored
usb-storage 2-1:1.2: device ignored
usb-storage 2-1:1.3: device ignored
usbcore: registered new interface driver usbserial
USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial Driver core
USB Serial support registered for GSM modem (1-port)
option 2-1:1.0: GSM modem (1-port) converter detected
usb 2-1: GSM modem (1-port) converter now attached to ttyUSB0
option 2-1:1.1: GSM modem (1-port) converter detected
usb 2-1: GSM modem (1-port) converter now attached to ttyUSB1
option 2-1:1.2: GSM modem (1-port) converter detected
usb 2-1: GSM modem (1-port) converter now attached to ttyUSB2
usbcore: registered new interface driver option
option: v0.7.2:USB Driver for GSM modems

Wohooo ein GSM Modem. Was sagt lsusb?

$ lsusb
Bus 002 Device 004: ID 19d2:0117 ONDA Communication S.p.A.

OK, der Stick wird nun also als Modem erkannt, die Datenlaufwerke werden ignoriert und ich könnte mich ja mal um eine Interneteinwahl kümmern, oder? Nötig ist dafür ppp und (weil es so schön einfach ist) wvdial. Emerge muss das wieder für mich erledigen:

$ emerge ppp wvdial

Nach kurzer Zeit ist er fertig. Nun lege ich mal das ppp Device an:

$ mknod /dev/ppp c 108 0

*umschau* ich habe ja so ein paar Tests hinter mir und Scripte können da knallhart sein. Wenn man denen sagt: „Probiere mal bis geht…“ Dann tun die das auch wenn sie 100 mal die falsche PIN eingeben. Man kann lange suchen bis man darauf kommt die PUK einzugeben. SEHR lange. Ich habe also die PIN-Eingabe abgeschaltet!


wvdial ist schnell konfiguriert. Meine Konfiguration für O2 schaut so aus:

[Dialer Defaults]
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 +FCLASS=0
Modem Type = Analog Modem
Baud = 460800
New PPPD = yes
Modem = /dev/ttyUSB2
ISDN = 0

[Dialer pin]

[Dialer o2]
Modem = /dev/ttyUSB2
Dial Command = ATD
Carrier Check = no
Phone = *99#
Password = guest
Username = guest
Stupid Mode = 1
Init3 = AT+ZSNT=0,0,2, AT+ZOPRT=5
Init4 = AT+CGDCONT=1,"IP","pinternet.interkom.de"
Dial Attempts = 2

Stecke ich nun meinen (mit abgeschalteter PIN-Eingabe) Surfstick ins Notebook beginnt er rot zu leuchten. Ist der Stick betriebsbereit und hat Netz beginnt er grün zu leuchten 🙂 Einfach, oder?

ZTE MF190 HSUPA USB surfstick with SIM lock
ZTE MF190 USB surfstick after SIM unlock

Die Einwahl funktioniert nun recht einfach mit wvdial:

$ wvdial o2
--> WvDial: Internet dialer version 1.61
--> Cannot get information for serial port.
--> Initializing modem.
--> Sending: ATZ
ATZ
OK
--> Sending: ATQ0 V1 E1 S0=0 &C1 +FCLASS=0
ATQ0 V1 E1 S0=0 &C1 +FCLASS=0
OK
--> Sending: AT+ZOPRT=5
AT+ZOPRT=5
OK
--> Sending: AT+CGDCONT=1,"IP","pinternet.interkom.de"
AT+CGDCONT=1,"IP","pinternet.interkom.de"
OK
--> Modem initialized.
--> Sending: ATD*99#
--> Waiting for carrier.
ATD*99#
CONNECT 7200000
--> Carrier detected.  Starting PPP immediately.
--> Starting pppd at Tue Mar  8 20:35:06 2011
--> Pid of pppd: 22068
--> Using interface ppp0
--> local  IP address 10.151.95.132
--> remote IP address 10.64.64.64
--> primary   DNS address 193.189.244.225
--> secondary DNS address 193.189.244.206
Mobile network connection established via surfstick

Nun sollte man auch schon online sein. Ein kurzer Blick auf die Interfacekonfiguration zeigt:

$ ifconfig
lo        Protokoll:Lokale Schleife  
inet Adresse:127.0.0.1  Maske:255.0.0.0
inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine
UP LOOPBACK RUNNING  MTU:16436  Metric:1
RX packets:1030 errors:0 dropped:0 overruns:0 frame:0
TX packets:1030 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:83580 (81.6 KiB)  TX bytes:83580 (81.6 KiB)

ppp0      Protokoll:Punkt-zu-Punkt Verbindung  
inet Adresse:10.151.95.132  P-z-P:10.64.64.64  Maske:255.255.255.255
UP PUNKTZUPUNKT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
RX packets:8360 errors:0 dropped:0 overruns:0 frame:0
TX packets:9926 errors:0 dropped:34 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:3
RX bytes:2446573 (2.3 MiB)  TX bytes:5945120 (5.6 MiB)

sixxs     Protokoll:UNSPEC  Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
inet6 Adresse: 2a01:198:200:a79::2/64 Gültigkeitsbereich:Global
inet6 Adresse: fe80::98:200:a79:2/64 Gültigkeitsbereich:Verbindung
UP PUNKTZUPUNKT RUNNING NOARP MULTICAST  MTU:1280  Metric:1
RX packets:1007 errors:0 dropped:0 overruns:0 frame:0
TX packets:973 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:500
RX bytes:880413 (859.7 KiB)  TX bytes:234147 (228.6 KiB)
Mobile internet connection active on Gentoo Linux

Wie zu erkennen ist steht auch die Verbindung zu meinem Tunnelbroker Sixxs. Somit ist mein Notebook auch per IPv6 unterwegs 🙂

Also, viel Spaß beim Surfen.


*Update*

Wer >>hier<< nachliest wird sehen, dass man den Flashdrive-Modus auch komplett deaktivieren kann.

Man kann hier zwei Wege gehen das zu tun:

1. Einmalig das ganze im Int3 mitgeben:

Init3 = AT+ZCDRUN=9, AT+ZSNT=0,0,2, AT+ZOPRT=5

2. Minicom.

Datenrettung mit Linux: ntfsundelete, ddrescue und PhotoRec im Praxistest

Ich wollte wissen, wie gut sich Daten mit Linux-Bordmitteln wiederherstellen lassen. Also habe ich eine alte Festplatte genommen und es systematisch ausprobiert. Erst normal gelöschte Dateien, dann ein RAW-Image, und am Ende habe ich die Platte physisch zerstört, um zu sehen was ddrescue und PhotoRec aus den Trümmern holen.

Vorbereitung: Testplatte befüllen

Die älteste funktionierende Platte aus meinem Fundus: eine WD Expert 136BA. Erst komplett mit Nullen überschrieben, dann partitioniert und als NTFS formatiert:

dd if=/dev/zero of=/dev/sdb1
mkfs.ntfs -L TestDatenloeschung -T /dev/sdb1

Einen ca. 1,53 GB großen Ordner mit verschiedensten Dateien habe ich dann so lange auf die Platte kopiert, bis sie voll war.

Dolphin zeigt die Ordner auf der Festplatte
kdf zeigt: Festplatte ist voll

ntfsundelete: Gelöschte Dateien wiederherstellen

Erster Scan, noch ohne etwas gelöscht zu haben:

ntfsundelete -s /dev/sdb1
# Files with potentially recoverable content: 0

Logisch, es wurde ja noch nichts gelöscht. Also ein paar Dateien weg und erneut scannen:

ntfsundelete -s /dev/sdb1
# Files with potentially recoverable content: 154

154 Dateien. Jetzt die Wiederherstellung:

ntfsundelete /dev/sdb1 -u -m '*.*' -p 100 -d /test

Die Optionen: -u für Undelete-Modus, -m '*.*' für alle Dateien (mit -m '*.doc' könnte man nur Word-Dateien holen), -p 100 für nur zu 100 % wiederherstellbare Dateien, -d /test als Zielverzeichnis. Bei Bildern könnte man den Prozentsatz auch niedriger setzen, Teile eines JPEG sind besser als nichts.

Alle 154 Dateien kamen vollständig zurück. Einzige Einschränkung: Dateien mit gleichem Namen werden nicht überschrieben. Sollte man beachten oder per Script lösen.

Arbeiten mit RAW-Images

Im Ernstfall arbeitet man nie mit der Originalplatte. Sobald man den Datenverlust bemerkt, am besten sofort den Stecker ziehen. Jeder weitere Betrieb, selbst ein Herunterfahren, kann die gelöschten Daten überschreiben. Also erst ein RAW-Image ziehen:

dd if=/dev/sdb1 of=/001/TestRettung.img
# 26709984+0 Datensätze ein
# 13675511808 Bytes (14 GB) kopiert, 701,766 s, 19,5 MB/s

ntfsundelete funktioniert genauso mit dem Image-File. Gleiche Ergebnisse, gleiche Wiederherstellung. Genau so soll es sein.

Die Festplatte zerstören

Jetzt wird es interessant. Mich hat natürlich interessiert, was bei einer physisch beschädigten Platte passiert. Also Platte wieder voll gemacht und dann aufgeschraubt.

Festplatte mit freigelegten Gehäuseschrauben
Geöffnete Festplatte, bereit zur Zerstörung

Vorsichtig ein paar Kratzer mit dem Schraubendreher auf die Magnetscheiben gesetzt. Nicht zu viel, aber genug, dass einige Gigabyte unlesbar sein sollten.

Festplatte wird mit einem Schraubendreher zerkratzt
Geöffnete Festplatte wird mit einem Schraubendreher zerkratzt
Geöffnete Festplatte mit zerkratzten Magnetscheiben

ddrescue: 52 Stunden an einer zerkratzten Platte

Platte wieder zugeschraubt und ddrescue drauf losgelassen:

ddrescue -n /dev/sdb1 /001/datenrettung.img /001/datenrettung.log
ddrescue -d -n -r3 /dev/sdb1 /001/datenrettung.img /001/datenrettung.log
ddrescue bei der Arbeit

Nach meiner kleinen Kratzorgie hat ddrescue 52 Stunden an der Platte gefummelt, bevor es durch war.

Wann zum Profi?

Wenn einem die Daten mehr als 3.000 Euro wert sind, sollte man einen professionellen Datenretter aufsuchen. Die nehmen zur Diagnose oft um die 90 Euro und sagen dann, was es wirklich kostet. Bei einem Fall aus 2010 hat ein Kunde mit einer 160 GB HDD und Headcrash einen Kostenrahmen von 15.000 bis 18.000 Euro genannt bekommen. Jede Bewegung an der Platte kann weitere Daten zerstören.

Ich habe selbst mal bei einer Seagate SCSI-Platte die komplette Elektronik von einer baugleichen getauscht, weil sie keinen Spin-Up mehr machte. Lief danach wieder, als wäre nie etwas gewesen. Auch ein Tausch der Schreib-/Leseköpfe hat einmal funktioniert, nachdem einer halb abgerissen war. Die Platte sprang genau ein Mal an, ich konnte sichern, beim nächsten Versuch ging nichts mehr. Solche Experimente klappen nicht immer. Hat man an der Platte herumgefummelt, hat oft auch der Profi keine Chance mehr.

PhotoRec: Dateien anhand des Headers retten

Das ddrescue-Image ließ sich in meinem Fall nicht mehr mounten. Durch die Kratzer war auch das NTFS-Dateisystem total im Eimer, selbst fsck half nicht. Also brauchte ich ein Programm, das Dateien anhand ihres Headers wiederherstellen kann: PhotoRec.

photorec datenrettung_parti_sicher.img
PhotoRec: Auswahl der Festplatte
PhotoRec: Auswahl der Partition
PhotoRec: Auswahl des Dateisystems
PhotoRec bei der Arbeit

PhotoRec hat erstaunlich viele Dateien aus der zerkratzten Platte zurückgeholt. Wer sich das Programm anschaut, sollte sich auch TestDisk vom gleichen Entwickler ansehen. Damit lassen sich gelöschte Partitionen rekonstruieren und noch vieles mehr.

TestDisk mit RAW-Image

Update 2026: Was bei SSDs und NVMe anders ist

Der Beitrag oben ist von 2010 und das merkt man. Die meisten Endgeräte haben heute keine drehende Festplatte mehr, sondern eine SSD oder NVMe. Das ändert das Spiel komplett.

Sobald TRIM oder UNMAP aktiv sind, meldet das Dateisystem dem Controller, welche Blöcke nach einem DELETE freigegeben sind. Der Controller löscht diese Zellen oft sofort oder beim nächsten Garbage-Collection-Lauf. Ergebnis: ntfsundelete oder PhotoRec laufen ins Leere, weil die Daten physisch schon weg sind. Wer ein Recovery-Tool an einer SSD ansetzt, sollte das Laufwerk vorher per Software-Hardware-Befehl ruhigstellen, also nicht mounten und keine TRIM-Befehle mehr absetzen lassen.

NVMe legt noch eine Schaufel drauf. Mit nvme sanitize oder nvme format --ses=1 ist nach Sekunden alles weg, kryptografisch sauber. Das ist gut für Hardware-Verkauf oder -Entsorgung, ein Albtraum für Recovery.

Verschlüsselte Datenträger sind ein eigenes Kapitel. BitLocker, LUKS, FileVault, APFS-Encryption: ohne den Schlüssel oder das Recovery-Passwort hilft kein Tool der Welt. Bei einem PCB-Defekt einer SSD wird es zusätzlich kritisch, weil moderne Controller die Verschlüsselung intern anders handhaben als der Host. Selbst wenn die NAND-Chips noch heile sind, bekommt ohne den passenden Controller-State niemand mehr Klartext zurück. Mit anderen Worten: ein einfacher PCB-Tausch wie bei meiner alten Seagate SCSI ist 2026 nicht mehr drin, schon gar nicht im Selbstbau.

Update 2026: Backup schlägt Recovery

Die ehrliche Wahrheit nach 15 Jahren: ich habe nicht mehr ein einziges Mal in echt eine Datenrettung gemacht. Nicht weil die Tools schlechter geworden wären, sondern weil ich Backups habe. Wenn eine Platte stirbt, ziehe ich den letzten Snapshot zurück und gut ist. Recovery ist die Notlösung, wenn das Backup fehlt oder kaputt ist.

Was ich heute tatsächlich nutze:

  • ZFS-Snapshots mit zfs-auto-snapshot: stündlich, täglich, wöchentlich. Auf der Workstation und im Storage. Versehentliches rm -rf oder ein Crypto-Trojaner sind in Sekunden zurückgerollt.
  • zfs send / zfs recv auf einen externen Pool und auf ein Offsite-System. Inkrementell, verschlüsselt mit zfs send -w, vollautomatisch per Cron.
  • Borg / Restic für die Geräte, die kein ZFS sprechen. Deduplizierend, verschlüsselt, push und pull-Modi.
  • Time Machine auf dem MacBook, weil es genau das macht was es soll.

Die 3-2-1-Regel ist alt und immer noch korrekt: drei Kopien, auf zwei verschiedenen Medien, eine davon räumlich getrennt. Cloud-Sync wie Dropbox, OneDrive oder Google Drive ist dabei kein Backup. Wenn dort etwas gelöscht wird, ist es im selben Moment auch lokal weg. Ein Backup ist immer eine Kopie, die nicht automatisch mitläuft.

Update 2026: Tools und Preise heute

Die guten Nachrichten zuerst: alle vier Tools aus dem Original werden weiter aktiv gepflegt.

  • GNU ddrescue: aktuell Version 1.28, läuft auf jedem Linux/BSD/macOS. Mit ddrescueview gibt es eine GUI, die das Mapfile visualisiert.
  • PhotoRec / TestDisk: Version 7.2, von cgsecurity.org. Versteht inzwischen über 500 Dateiformate, auch moderne wie HEIC, AVIF, MKV-Container.
  • ntfsundelete: Teil der ntfs-3g/ntfsprogs, weiterhin im Standard-Repository jeder Distribution.
  • SMART und Vorhersage: smartctl aus smartmontools ist Pflicht. Die Werte Reallocated_Sector_Ct, Current_Pending_Sector und Offline_Uncorrectable sagen oft schon Tage vorher, dass die Platte sterben wird.

Bei den Preisen für professionelle Datenrettung hat sich einiges getan. Die Diagnose liegt heute meist zwischen 50 und 200 Euro, oft sogar kostenlos wenn man den Auftrag erteilt. Die eigentliche Rettung ist stark gestaffelt: einfache Logikfehler ab etwa 300 Euro, mechanische Defekte mit Reinraum ab 800 bis 1.500 Euro, schwere Schäden mit Plattentausch und Adaption-Tabellen können immer noch vier- bis fünfstellig werden. Anbieter wie CBL, Ontrack oder Stellar geben kostenlose Erstdiagnose, das nutze ich heute auch wenn nur ein Verdacht im Raum steht.

Ein Hinweis noch: SSD- und NVMe-Recovery ist deutlich teurer als HDD-Recovery, weil der Reinraum-Aufwand durch teure Equipment-Setups für NAND-Reads ersetzt wird. Wer also wirklich wichtige Daten auf einer SSD hatte, fährt mit einem soliden Backup-Konzept finanziell und nervlich besser.

Fazit

Für normal gelöschte Dateien auf NTFS reicht ntfsundelete. Bei physischen Schäden ist ddrescue das Mittel der Wahl, um erst ein Image zu sichern. Und wenn das Dateisystem komplett zerstört ist, kann PhotoRec anhand der Datei-Header noch erstaunlich viel retten. Wichtigste Regel: Nie an der Originalplatte arbeiten, immer zuerst ein Image ziehen.

2026 gilt das alles weiter, mit zwei Einschränkungen. Auf SSDs und NVMe kommt man oft schon gar nicht mehr an die Daten. Und: das beste Recovery ist das, das man nie machen muss. Backup, Backup, Backup.

Siehe auch: FreeBSD: Automatische ZFS-Snapshots mit zfs-auto-snapshot, FreeBSD: ZFS-Datensicherung mit Snapshots und zfs send/recv und FreeBSD: Verschlüsseltes ZFS-Backup auf USB-Platte mit geli.

Fragen? Einfach melden.

Dovecot Quota einrichten: Postfachgröße begrenzen mit Warnungen und SQL

Ohne Quota wachsen IMAP-Postfächer bis die Platte voll ist. Dovecot bringt ein Quota-Plugin mit, das die Postfachgröße begrenzt und den Benutzer warnt bevor es eng wird. Bei vollem Postfach kann Dovecot eingehende Mails mit einem temporären Fehler abweisen, statt sie sofort zu bouncen. So hat der Benutzer Zeit aufzuräumen.

Plugin aktivieren

In conf.d/20-imap.conf und conf.d/20-lmtp.conf (oder 15-lda.conf) das Quota-Plugin laden:

# 20-imap.conf
protocol imap {
  mail_plugins = $mail_plugins quota imap_quota
}

# 20-lmtp.conf
protocol lmtp {
  mail_plugins = $mail_plugins quota
}

imap_quota sorgt dafür dass Mailclients die Quota-Information per IMAP abfragen können (GETQUOTA/GETQUOTAROOT). Die meisten Clients zeigen dann einen Fortschrittsbalken.

Quota-Backend und Standardgröße

In conf.d/90-quota.conf:

plugin {
  quota = count:User quota
  quota_vsizes = yes
  quota_rule = *:storage=512M
}

count ist das empfohlene Backend ab Dovecot 2.2+. Es speichert die Quotadaten in der Index-Datei und muss nicht jedes Mal alle Mails auf der Platte zählen. Das alte dirsize-Backend funktioniert zwar noch, wird aber bei großen Postfächern langsam. quota_rule = *:storage=512M setzt die Standardgröße für alle Postfächer auf 512 MB.

Quota Warnings

Dovecot kann bei bestimmten Schwellenwerten ein Script aufrufen, das eine Warnung verschickt:

plugin {
  quota_warning = storage=80%% quota-warning 80 %u
  quota_warning2 = storage=95%% quota-warning 95 %u
}

service quota-warning {
  executable = script /usr/local/bin/quota-warning.sh
  user = vmail
  unix_listener quota-warning {
    user = vmail
  }
}

Die doppelten Prozentzeichen (%%) sind nötig weil Dovecot % als Variablen-Prefix interpretiert. Das Script /usr/local/bin/quota-warning.sh bekommt den Schwellenwert und die E-Mail-Adresse als Parameter:

#!/bin/sh
PERCENT=$1
USER=$2
echo "Ihr Postfach $USER ist zu $PERCENT% belegt.
Bitte loeschen oder archivieren Sie aeltere E-Mails." | \
  mail -s "Postfach $USER: $PERCENT% belegt" "$USER"

Individuelle Quotas per SQL

Wenn nicht jeder Benutzer die gleiche Postfachgröße bekommen soll, lässt sich die Quota per SQL-Abfrage pro Benutzer setzen. In der dovecot-sql.conf.ext:

user_query = SELECT \
  home, uid, gid, \
  CONCAT('*:storage=', quota_mb, 'M') AS quota_rule \
  FROM virtual_users \
  WHERE email = '%u'

Die Tabelle virtual_users braucht dafür ein Feld quota_mb. Dovecot übernimmt den Wert aus dem SQL-Ergebnis und überschreibt damit die Standardregel aus der Config. Benutzer ohne Eintrag bekommen weiterhin die 512 MB aus quota_rule.

Verhalten bei vollem Postfach

Standardmäßig gibt Dovecot bei vollem Postfach einen permanenten Fehler zurück und Postfix bounced die Mail. Mit der folgenden Einstellung wird stattdessen ein temporärer Fehler gesendet (4xx), damit Postfix die Mail in der Queue behält und es später nochmal versucht:

plugin {
  quota_exceeded_message = Quota exceeded, please try again later.
}

# In der LDA/LMTP Config:
quota_full_tempfail = yes

So hat der Empfänger Zeit sein Postfach aufzuräumen, ohne dass Mails verloren gehen. Fragen? Einfach melden.

Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑