ZFS Storage sicher löschen

[jb_alvarado]

Hallo Allerseits,
ich habe hier ein altes Disk Array, wo ein ZFS Pool drauf lief. Dieses möchte ich sicher löschen, dass die Daten nicht wiederhergestellt werden können.

Kennt ihr eine einfache und schnelle Möglichkeit das zu bewerkstelligen? Ich hoffe halt, dass ich drum rum komme, jede einzelne Platte mehrfach zu überschrieben, auch den ganzen Pool überschrieben würde ziemlich lange dauern.

Kann man nicht irgendwie die ZFS Metadaten, Header, oder was weiß ich zerstören, so das der Plattenverbund nicht mehr wiederhergestellt werden kann? Das müsste doch eigentlich reichen, oder?

 

[Trefoil80]

Weiß nicht, wie das mit einem ZFS Pool ist, aber normalerweise benutze ich DBAN und überschreibe exakt einmal mit Zufallszahlen.

 

[madmax2010]

1x ueberschreiben. Um mit ranndom oder sonst was ist egal.

 

[Humptidumpti]

Einmal überschrieben und fertig. Ob du jetzt den Pool, das Array oder jede einzelne Platte hier überschreibst ist völlig wurscht.

 

[KillerCow]

Kann man nicht irgendwie die ZFS Metadaten, Header, oder was weiß ich zerstören, so das der Plattenverbund nicht mehr wiederhergestellt werden kann? Das müsste doch eigentlich reichen, oder?

Das wäre dann ähnlich einer "Schnellformatierung". Macht ein Datenwiederherstellen definitiv schwieriger, aber wie der Name schon sagt: Metadaten sind eben nicht die Nutzdaten. Willst du sicher sein, dann überschreib die Platten einmal komplett, wie bereits gesagt wurde.

 

[jb_alvarado]

Hm, ok. Sind halt ~10TB, hatte gehofft dem entgehen zu können :-).

Ist es dann nicht schneller, wenn ich das parallelisiere und die Platten einzeln, aber zur gleichen Zeit überschreiben?

 

[snaxilian]

Du kannst alle Disks einzeln ansprechen und parallel überschreiben.

Oder du machst ein Raid 0 über alle Disks und schreibst drauf los. Sehr hohe Schreibgeschwindigkeit da verteilt über alle aber musst eben mehr Daten schreiben insgesamt.

Oder du machst ein Raid 1 über alle Disks, also quasi ein mehrfacher Spiegel und schreibst da drauf. Du musst nur einmal den Schreibprozess starten und hast am Ende auf allen Disks identischen "Datenmüll".

Würde mich ja mal interessieren welche der drei Methoden am schnellsten geht.
Wenn es nicht gerade SMRs sind wovon ich bei ZFS nicht ausgehe, hast pro Disk pessimistisch geschätzt 120 MB/s im Durchschnitt, vermutlich eher mehr. Also 7200 MB/Min oder auch 432.000 MB/Stunde.
Oder 432 GB/Stunde.
Wenn du mit ~10TB die Kapazität pro Disk meinst, bist doch nach einem Tag durch mit dem Spaß bzw. nach ca 3 Tagen wenn du uns allen Gewissheit schaffst und alle drei Szenarien durch testest^^

Ja, wir haben hier wunderbare Ungenauigkeiten da unklar ist ob wir jetzt Mega- oder Mibibyte meinen oder in 1000er oder 1024er Schritten rechnen sollten. Ich nehme einfach 1000er, dann ist die Realität im besten Fall einfach schneller

 

[Humptidumpti]

Hirn einschalten. Die Schreibgeschwindigkeit einer jeden Festplatte ist mechanisch begrenzt. Ob die jetzt im Array hängen oder einzeln angesprochen werden ändert doch nix daran dass eine Menge X an Daten überschrieben werden muss. Dauert also überall gleich lange.

 

[jb_alvarado]

@snaxilian, das ist eine gute Idee mit den Raid Leveln. Insgesamt hat das Array 25 Disks a 900GB. In Verwendung waren aber etwas weniger. Ich denke, ich erstelle einen Pool mit Mirror VDevs (Raid 1). Ein Raid 0 würde wahrscheinlich durch das Mini-SAS Kabel ausgebremst werden.

 

[madmax2010]

Nicht unbedingt. RAID0 (wobei in der praxis eher raid 10 ) wurde in dem Kontext eher genutzt um die IOPS hoch zu bekommen, die datenrate ist da zweitrangig. Das ist aber auch eher so ein ding aus einer Zeit bevor SSDs verfuegbar und billig waren. Heute ist eine einzelne MX500 in dem Aspekt performanter, als 25 900GB SAS Disks.
Aber ja, beim loeschen limitiert dich die Anbindung.

 

[snaxilian]

@Humptidumpti Sehe ich nicht unbedingt so, sobald man die Vorgänge parallelisieren kann und sonst keine Limitierungen hat.
Wenn der TE zwei oder mehrere HDDs parallel überschreiben kann, addiert sich doch die Dauer nicht. Klar ist die Schreibgeschwindigkeit pro einzelner HDD begrenzt.
Wenn aber beispielsweise die Parallelisierung Probleme mit sich bringt wie z.B. verzögerte Lieferung der Zufallsdaten bei parallelen Zugriffen auch wenn das eher ein theoretisches Problem ist.
mich würde v.a. interessieren ob es länger dauert die Disks zu überschreiben wenn diese ein Raid 0 oder ein simples JBOD sind. Raid 1 oder manuelle Parallelisierung sollte so oder so schneller sein.

Nachtrag:
@jb_alvarado Nimm doch gleich three-way mirror (oder noch mehr). Weiß gar nicht wo da das Limit ist wie viele mirrors pro vdev maximal möglich sind. Im optimalsten Fall kannst eine einzelne 25-way mirrored vdev anlegen, Pool mit der einen vdev erstellen und musst nur einmalig 900 GB schreiben in den Pool und hast dann 25x identischen Datenmüll
Random IOPS sind ja egal, da du nur linear schreiben willst, daher machen mehrere vdevs keinen Sinn außer du kannst nicht beliebig viele mirror pro vdev anlegen.

 

[jb_alvarado]

Nachtrag:
@jb_alvarado Nimm doch gleich three-way mirror (oder noch mehr). Weiß gar nicht wo da das Limit ist wie viele mirrors pro vdev maximal möglich sind. Im optimalsten Fall kannst eine einzelne 25-way mirrored vdev anlegen, Pool mit der einen vdev erstellen und musst nur einmalig 900 GB schreiben in den Pool und hast dann 25x identischen Datenmüll
Random IOPS sind ja egal, da du nur linear schreiben willst, daher machen mehrere vdevs keinen Sinn außer du kannst nicht beliebig viele mirror pro vdev anlegen.

Stimmt du hast recht! Anscheint kann man belibig viele HDs in ein Mirror VDev packen. Quelle: multiple_disks

 

[snaxilian]

Bei einem 25-Way-Mirror und niedrig geschätzten 120 MB/s ergibt das wie schon genannt 432 GB/Stunde, nach der Einrichtung müsstest du in circa knapp 2h durch sein.

 

[jb_alvarado]

Musste bis jetzt erst mal CentOS auf einen alten Server (HP DL 360 G5) drauf bekommen. Das hat nämlich den alten Controller (Smart Array P400i) nicht erkannt. Live CD ging auch nicht. Zu guter Letzt habe ich jetzt CentOS 7 auf eine USB 2.0 Festplatte installiert.

Brauchte auch noch einen vernünftigen Zufallsgenerator. Hier der Benchmark :

# cat /dev/zero | pv > /dev/null
^C21GiB 0:00:05 [1,32GiB/s]

# cat /dev/random | pv > /dev/null
^C,8kiB 0:00:06 [2,78kiB/s]

# cat /dev/srandom | pv > /dev/null
^C96GiB 0:00:07 [ 878MiB/s]

Pool erstellen geht ja einfach, das liebe ich an ZFS:

zpool create -m /mnt/pool pool -f -o ashift=12 mirror /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf /dev/sdg /dev/sdh /dev/sdi /dev/sdj /dev/sdk /dev/sdl /dev/sdm /dev/sdn /dev/sdo /dev/sdp /dev/sdq /dev/sdr /dev/sds /dev/sdt /dev/sdu /dev/sdv /dev/sdw /dev/sdx /dev/sdy /dev/sdz

Und noch mal verifizieren:

# df -h
Dateisystem             Größe Benutzt Verf. Verw% Eingehängt auf
...
pool                     806G    128K  806G    1% /mnt/pool

# zpool status
  pool: pool
state: ONLINE
  scan: none requested
config:

    NAME        STATE     READ WRITE CKSUM
    pool        ONLINE       0     0     0
      mirror-0  ONLINE       0     0     0
        sdb     ONLINE       0     0     0
        sdc     ONLINE       0     0     0
        sdd     ONLINE       0     0     0
        sde     ONLINE       0     0     0
        sdf     ONLINE       0     0     0
        sdg     ONLINE       0     0     0
        sdh     ONLINE       0     0     0
        sdi     ONLINE       0     0     0
        sdj     ONLINE       0     0     0
        sdk     ONLINE       0     0     0
        sdl     ONLINE       0     0     0
        sdm     ONLINE       0     0     0
        sdn     ONLINE       0     0     0
        sdo     ONLINE       0     0     0
        sdp     ONLINE       0     0     0
        sdq     ONLINE       0     0     0
        sdr     ONLINE       0     0     0
        sds     ONLINE       0     0     0
        sdt     ONLINE       0     0     0
        sdu     ONLINE       0     0     0
        sdv     ONLINE       0     0     0
        sdw     ONLINE       0     0     0
        sdx     ONLINE       0     0     0
        sdy     ONLINE       0     0     0
        sdz     ONLINE       0     0     0

Schreibgeschwindigkeit hält sich allerdings doch sehr in Grenzen:

# cat /dev/srandom | pv > /mnt/pool/trash.file

Bringt ca. 28,5 MiB/s. Vermute mal, dass das Mini SAS das Nadelöhr ist. Es müssen ja alle Drives gleichzeitig beschrieben werden.Würde rechnerisch hinkommen:

6 Gbit/s (Mini SAS) macht 715,2557 MiB/s, geteilt durch 25 macht 28,610228 MiB/s

 

[snaxilian]

Für die Zukunft würde vermutlich auch folgendes gehen:
zpool create -m /mnt/pool pool -f -o ashift=12 mirror /dev/sd[b-z]
Zumindest klappt diese Art der Zusammenfassung bei mdadm aber es sollte auch bei ZFS funktionieren.

 

[TheCadillacMan]

6 Gbit/s (Mini SAS) macht 715,2557 MiB/s, geteilt durch 25 macht 28,610228 MiB/s

miniSAS hat vier gleichzeitige 6 Gbit/s-Verbindungen. Hier schient das noch nicht zu limitieren.

 

[HisN]

Verteilt der Pool die Daten nicht über die Platten?
Was kann dann tatsächlich wieder hergestellt werden, wenn man nur einen n-Teil der Platten hat?
Am Ende kann man selbst dann nix wiederherstellen, selbst wenn da kein dban drübergelaufen ist, einfach weil man nur einen kleinen Teil der Daten hat.
Nebenbei müsste man schon erhebliche kriminelle Energie und Linux-Erfahrung mitbringen um ein Teil-ZFS überhaupt lesen zu können.

Ich bezweifle dass das der 0815 Windows User oder Scriptkiddie da auch nur in die Nähe irgendwelcher Daten kommt.

 

[jb_alvarado]

miniSAS hat vier gleichzeitige 6 Gbit/s-Verbindungen. Hier schient das noch nicht zu limitieren.

Interessant, aber wie kommt dann genau die ~28,5 MiB/s zustande? Wenn ich einen zweiten Schreibvorgang startet gehen beide runter auch ~14,2 MiB/s.

Wahrscheinlich hast du recht @HisN. Die Dateien verteilen sich über den Pool. Deshalb ist es suboptimal in Sachen Performance, wenn man später, wenn der Pool schon fast voll ist, VDevs dazu tut.

 

[snaxilian]

@jb_alvarado Wenn die Disks in den nachträglich hinzugefügten VDEVs identisch zu den vorhandenen ist, werden bei neuen Daten bevorzugt die neuen VDEVs befüllt bis wieder Gleichstand herrscht, ab dann wieder alle. Ergibt zwar einen Performance-Impact aber dafür gleiche Belegung. Daher sollte man bestehende Pools nicht unnötig erweitern wenn Performance ein relevanter Faktor ist sondern anfangs vernünftig planen oder im Nachhinein zweiten Pool parallel aufbauen und Daten mit zfs send | receive migrieren^^

@HisN Ja korrekt aber die theoretische Möglichkeit der Wiederherstellung reicht oft genug aus sodass entweder ein überschreiben oder mechanische Zerstörung entsprechend durch Regularien oder unternehmensinterne Richtlinien vorgeschrieben ist.
Bei sowas geht es nicht immer nur um die technischen Aspekte sondern Haftungsfragen.

 

[HisN]

Und solche dann doch gewichtigen Umstände treiben jemanden dazu in einem normalen Forum nachzufragen wie man Daten löscht, und dazu noch keine Zeit für einen Durchlauf DBAN hat?
Meinst Du nicht, das dieser jemand nicht unbedingt in Deine Zielgruppe fällt?