Speicher

Unter Speicher verwaltest du Platten, ZFS-Pools, Datasets, Snapshots und die Speichergrenze des ZFS-Caches (ARC). Die Seite hat sieben Reiter: Pools, Platten, Datasets, Snapshots, Ruhezustand, Burn-in und ARC. Pools und Platten aktualisieren sich alle 5 Sekunden (während eines Scrubs alle 2 Sekunden).

Bunkerbox verwendet OpenZFS aus Debian contrib (zfs-dkms, zfsutils-linux). Fehlt ZFS, zeigt die Seite einen Hinweis; Platten werden trotzdem angezeigt.

Platten

Die Tabelle zeigt alle Platten mit Gerät, Seriennummer, Modell, Größe (Herstellerangabe, 1 TB = 10¹² Byte), Typ (HDD mit Drehzahl, SSD, NVMe), Temperatur, SMART-Zustand und Verwendung:

Verwendung	Bedeutung
Systemplatte	Trägt /, /boot, /boot/efi, /usr, /var oder aktiven Swap (auch über LVM oder LUKS) oder gehört zu einem Pool mit dem Root-Dateisystem. Wird nie für Pools angeboten.
Pool name	Mitglied eines importierten Pools.
Belegt	Enthält ein anderes Dateisystem, ist eingehängt oder gehört zu einem exportierten Pool. Wird nicht angeboten, damit keine Daten verloren gehen.
Frei	Kann für einen neuen Pool, ein weiteres vdev oder als Ersatz verwendet werden. Reste eines gelöschten Pools zählen als frei.

SMART-Werte stammen aus smartctl -j -a -n standby und werden höchstens alle 2 Minuten gelesen. Schlafende Platten werden dabei nicht geweckt; es bleiben die zuletzt bekannten Werte stehen. SMART neu lesen fragt alle Platten sofort ab. Details zeigt Firmware, Betriebsstunden und alle SMART-Attribute; auffällige Attribute sind rot markiert. Die Temperatur wird bei HDDs ab 46 °C gelb und ab 55 °C rot markiert, bei SSDs ab 60 °C bzw. 70 °C.

Pools

Jeder Pool erscheint als Karte mit Zustand (ONLINE, DEGRADED, …), Größe, Belegung, Fragmentierung, ashift, dem letzten oder laufenden Scrub bzw. Resilver, dem Scrub-Zeitplan, bekannten Datenfehlern und den Meldungen von zpool status (im englischen Originaltext). Darunter steht der Gerätebaum mit Lese-, Schreib- und Prüfsummenfehlern je Platte.

Pool anlegen

Pool anlegen öffnet den Layout-Baukasten:

1. Empfohlenes Layout: Bunkerbox schlägt für die freien Platten passende Pools vor und übernimmt sie mit einem Klick. HDDs werden nach Größe gruppiert: 2 Platten werden ein Mirror, 3 bis 5 ein RAIDZ1, 6 bis 12 ein RAIDZ2, mehr werden auf mehrere RAIDZ2 verteilt. Einzelne Platten neben redundanten Gruppen werden weggelassen, weil sie den ganzen Pool ungeschützt machen würden. SSDs und NVMe werden ein gespiegelter Pool apps für Apps und Docker-Daten. Für die Beispiel-Hardware (2 × 16 TB, 5 × 5 TB, 2 × 1 TB SSD) ergibt das tank = Mirror 2 × 16 TB + RAIDZ1 5 × 5 TB und apps = Mirror 2 × 1 TB.
2. Name, Sektorgröße und Kompression: ashift=12 (4 KiB) ist Standard und lässt sich später nicht ändern. Kompression standardmäßig lz4.
3. vdevs: Für jedes vdev Typ (Stripe, Mirror, RAIDZ1/2/3) und Rolle (Daten, Log, Cache, Ersatzplatte, Special) wählen und die Platten ankreuzen. Angeboten werden nur freie Platten.
4. Prüfung: Während der Eingabe zeigt Bunkerbox Rohkapazität, nutzbare Kapazität (vor ZFS-Verwaltungsaufwand) und Ausfallsicherheit. Fehler (zu wenige Platten, Systemplatte, belegte Platte, doppelte Auswahl) verhindern das Anlegen. Warnungen müssen ausdrücklich bestätigt werden:
   • unterschiedliche Redundanz der Daten-vdevs (z. B. Mirror neben RAIDZ1; zpool verlangt dafür -f),
   • Daten-vdevs ohne Redundanz,
   • unterschiedlich große Platten oder HDDs und SSDs gemischt in einem vdev,
   • zu schmale oder zu breite RAIDZ-vdevs, Special-vdev ohne Spiegel.
5. Bestätigung: Zum Anlegen muss der Pool-Name eingetippt werden. Alle Daten auf den gewählten Platten werden gelöscht.

Neue Pools werden immer über /dev/disk/by-id angelegt, damit sie nach einem Umstecken der Platten weiter funktionieren:

zpool create -o ashift=12 [-o autotrim=on] -O compression=lz4 -O atime=off -O xattr=sa \
  -O acltype=posixacl -O dnodesize=auto -m /<name> <name> mirror /dev/disk/by-id/... ...

autotrim=on wird gesetzt, wenn alle Datenplatten SSDs oder NVMe sind. -f wird nur nach bestätigten Warnungen verwendet; belegte Platten lehnt Bunkerbox vorher selbst ab.

Scrub

Scrub starten liest alle Daten des Pools und repariert Fehler aus der Redundanz; Scrub stoppen bricht ihn ab. Während eines Resilvers ist kein Scrub möglich. Unter Scrub-Zeitplan legst du einen wöchentlichen oder monatlichen Scrub fest (Wochentag bzw. Tag 1–28 und Stunde, Serverzeit). Bunkerbox prüft die Zeitpläne jede Minute; ein Termin, der in eine Ausfallzeit fiel, wird einmal nachgeholt. Läuft schon ein Scrub, wird der Termin übersprungen. Hinweis: Debian bringt in zfsutils-linux einen eigenen monatlichen Scrub mit (/etc/cron.d/zfsutils-linux); er kann zusätzlich laufen.

Platten tauschen

• Offline nimmt eine Platte aus dem Pool (optional nur bis zum Neustart), z. B. vor dem Ausbau. ZFS lehnt das ab, wenn dadurch zu viele Platten eines vdevs fehlen würden.
• Online nimmt sie wieder auf.
• Ersetzen tauscht eine Platte gegen eine freie, mindestens gleich große Platte (zpool replace). Danach läuft ein Resilver, dessen Fortschritt die Pool-Karte zeigt. Zur Bestätigung wird der Pool-Name eingetippt.

vdev hinzufügen, exportieren, importieren, löschen

• vdev hinzufügen erweitert den Pool um ein Daten-, Log-, Cache-, Ersatz- oder Special-vdev. Die Prüfung vergleicht die Redundanz mit den vorhandenen vdevs. Daten-vdevs lassen sich aus Pools mit RAIDZ nicht wieder entfernen; deshalb wird der Pool-Name zur Bestätigung verlangt.
• Exportieren hängt den Pool aus (zpool export), z. B. vor einem Umzug auf ein anderes System.
• Pool importieren sucht auf allen Platten nach exportierten oder fremden Pools (zpool import -d /dev/disk/by-id) und importiert den gewählten, optional unter neuem Namen.
• Löschen zerstört den Pool mit allen Daten (zpool destroy) nach Eingabe des Pool-Namens. Zugehörige Scrub- und Snapshot-Zeitpläne werden entfernt.

Exportieren und Löschen werden verweigert, solange Freigaben auf dem Pool liegen, der Pool das Betriebssystem oder die Bunkerbox-Installation (/appdata/bunkerbox) enthält, Apps mit laufenden Containern ihre Daten darauf haben oder Docker sein data-root darauf hat.

Datasets

Die Tabelle zeigt alle Dateisysteme als Baum mit Belegung, verfügbarem Platz, Kompression, Blockgröße, Quota, Einhängepunkt, Anzahl der Snapshots und Snapshot-Zeitplan. Ein * markiert Eigenschaften, die direkt am Dataset gesetzt (nicht geerbt) sind.

Dataset anlegen: übergeordnetes Dataset, Name und Verwendung wählen. Die Verwendung setzt passende Eigenschaften:

Verwendung	Eigenschaften
Allgemein	erbt alles
Medien	recordsize=1M
Apps und Datenbanken	recordsize=64K
Dokumente	compression=zstd

Zusätzlich einstellbar sind Kompression (off, lz4, zstd, zstd-fast, gzip, zle), Blockgröße (16K bis 1M), Quota, Reservierung, Einhängepunkt und atime. Gesetzt werden nur Werte, die vom übergeordneten Dataset abweichen; alles andere wird geerbt. Ein leerer Einhängepunkt bedeutet „geerbt“ (unterhalb des übergeordneten Datasets), none bedeutet „nicht eingehängt“. Systemverzeichnisse (/, /etc, /usr, /var, /boot, /root, /tmp, …) und /mnt/remotes sind als Einhängepunkt nicht erlaubt.

Bearbeiten ändert dieselben Eigenschaften (zfs set, bzw. zfs inherit für einen geleerten Einhängepunkt). Der Einhängepunkt lässt sich nicht ändern, solange Freigaben, die Bunkerbox-Installation oder Apps mit laufenden Containern darunter liegen.

Einhängepunkte werden vor dem Anlegen und Ändern geprüft: Systemverzeichnisse und ihre übergeordneten Verzeichnisse (z. B. /mnt wegen /mnt/remotes) sind nicht erlaubt, ebenso alles innerhalb der Bunkerbox-Installation. Ein Verzeichnis, unter dem schon etwas eingehängt ist oder das bereits Dateien enthält, wird nicht verdeckt – ZFS würde sonst seinen Inhalt unsichtbar machen.

Löschen verlangt den vollständigen Dataset-Namen. Hat das Dataset Unter-Datasets oder Snapshots, muss das Mitlöschen ausdrücklich angehakt werden. Das oberste Dataset eines Pools wird nur zusammen mit dem Pool gelöscht; Datasets mit Freigaben, in Systemverzeichnissen, mit der Bunkerbox-Installation, mit Daten laufender Apps oder mit Dockers data-root werden nicht gelöscht.

/appdata als Dataset

Für die Daten der Docker-Apps ist ein Dataset apps/appdata mit Einhängepunkt /appdata vorgesehen (siehe Apps). Weil Bunkerbox selbst unter /appdata/bunkerbox installiert ist, ist /appdata bereits ein nicht leeres Verzeichnis. Ein Dataset dort würde die laufende Installation verdecken; Bunkerbox lehnt das deshalb ab und bietet stattdessen die Übernahme an:

1. Datasets → Neues Dataset, übergeordnetes Dataset apps, Name appdata, Einhängepunkt /appdata.
2. „Vorhandenen Inhalt übernehmen“ aktivieren.
3. Alle Apps unter /appdata müssen gestoppt sein, und unterhalb von /appdata darf nichts anderes eingehängt sein.

Bunkerbox legt das Dataset dann mit overlay=on unter einem vorübergehenden Einhängepunkt (/mnt/bunkerbox-migrate/…) an, kopiert den Inhalt von /appdata mit cp -a hinein (Besitzer, Rechte, ACLs und erweiterte Attribute bleiben erhalten) und hängt es erst danach unter /appdata ein. Schlägt das Kopieren fehl, wird das neue Dataset wieder entfernt. Die Originaldateien bleiben unverändert unter dem Dataset liegen und belegen weiter Platz auf der Systemplatte; sie lassen sich später bei ausgehängtem Dataset entfernen. Das funktioniert genauso für jeden anderen nicht leeren Einhängepunkt.

Snapshots

Snapshots sind schreibgeschützte Stände eines Datasets. Die Liste lässt sich nach Dataset filtern und zeigt Name, Alter, belegten und referenzierten Platz.

• Snapshot anlegen: Dataset und Name wählen, optional mit allen Unter-Datasets (zfs snapshot -r). Namen, die mit auto- beginnen, sind für Zeitpläne reserviert.
• Zurücksetzen (zfs rollback) stellt den Stand des Snapshots wieder her; alle späteren Änderungen gehen verloren. Zur Bestätigung wird der vollständige Snapshot-Name (dataset@name) eingetippt. Gibt es neuere Snapshots, müssen sie mit „Neuere Snapshots löschen“ ausdrücklich freigegeben werden (zfs rollback -r).
• Löschen entfernt einen einzelnen Snapshot. Zur Bestätigung wird der vollständige Snapshot-Name eingetippt; die Prüfung erfolgt auch im Server.

Snapshot-Zeitpläne

Im Reiter Datasets öffnet Snapshots den Zeitplan eines Datasets: stündlich (Minute), täglich (Uhrzeit), wöchentlich (Wochentag und Uhrzeit) oder monatlich (Tag 1–28 und Uhrzeit), die Anzahl der aufzubewahrenden Snapshots (1–1000) und optional mit Unter-Datasets. Automatische Snapshots heißen auto-JJJJMMTT-HHMM. Nach jedem automatischen Snapshot werden die ältesten automatischen Snapshots über der Aufbewahrungszahl gelöscht; manuell angelegte Snapshots werden nie automatisch gelöscht.

ARC (ZFS-Speicher-Cache)

ZFS verwendet freien Arbeitsspeicher als Lese-Cache (ARC). Ohne Grenze kann der ARC so viel RAM belegen, dass Samba, Docker-Apps und das System knapp werden. Bunkerbox begrenzt ihn deshalb automatisch:

• Maximum = max(1 GiB, min(50 % des RAM, RAM − Reserve)) mit Reserve = max(4 GiB, 25 % des RAM)
• Minimum = RAM / 32, mindestens 256 MiB, höchstens die Hälfte des Maximums

RAM	Maximum	Minimum
4 GiB	1 GiB	256 MiB
8 GiB	4 GiB	256 MiB
16 GiB	8 GiB	512 MiB
32 GiB	16 GiB	1 GiB
64 GiB	32 GiB	2 GiB

Unter Grenzen manuell festlegen lassen sich Maximum (mindestens 512 MiB, höchstens RAM − 1 GiB) und Minimum (mindestens 64 MiB, kleiner als das Maximum) selbst setzen; ein leeres Minimum bleibt automatisch. Die wirksamen Werte werden beim Dienststart und bei jedem Anwenden sofort über /sys/module/zfs/parameters/zfs_arc_max bzw. zfs_arc_min gesetzt und in /etc/modprobe.d/bunkerbox-zfs.conf gespeichert, damit sie auch nach einem Neustart gelten. Wird das ZFS-Modul aus der initramfs geladen (Root auf ZFS oder installiertes zfs-initramfs), zeigt die Seite einen Hinweis: dann einmal update-initramfs -u ausführen.

Der Reiter zeigt außerdem die aktuelle ARC-Größe, das Ziel, die aktuell wirksamen Grenzen und die Trefferquote seit dem Start (aus /proc/spl/kstat/zfs/arcstats). Größe und Trefferquote stehen auch auf dem Dashboard.

Benachrichtigungen

Alle 5 Minuten prüft Bunkerbox Pools und Platten und meldet über die Benachrichtigungen: beeinträchtigte (DEGRADED) und ausgefallene Pools (FAULTED, UNAVAIL, SUSPENDED, REMOVED), Lese-, Schreib- oder Prüfsummenfehler einer Platte, Scrubs mit Fehlern, einen fehlerhaften SMART-Status, steigende Defektzähler (neu zugewiesene, ausstehende oder nicht korrigierbare Sektoren) und zu heiße Platten (HDD ab 55 °C, SSD und NVMe ab 70 °C). Dieselbe Meldung wird nicht wiederholt, solange sich der Zustand nicht ändert.

Sicherheit

• Alle Befehle (zpool, zfs, smartctl, lsblk) werden mit Argument-Listen ohne Shell gestartet. Pool-, Dataset- und Snapshot-Namen, Platten-IDs und Pfade werden vorher streng geprüft; an zpool gehen nur Gerätepfade, die Bunkerbox selbst ermittelt hat.
• Zerstörende Aktionen (Pool anlegen oder löschen, vdev hinzufügen, Platte ersetzen, Dataset löschen, Zurücksetzen) verlangen die getippte Bestätigung. Geprüft wird im Dienst, nicht nur in der Oberfläche.
• Systemplatten und belegte Platten werden nie angeboten und vom Dienst abgelehnt.
• Snapshots werden nur mit einem Namen der Form dataset@name gelöscht, damit nie versehentlich ein Dataset zerstört wird.
• Solange ein Vorgang läuft (z. B. Pool anlegen oder löschen), werden Updates zurückgehalten.

Mock-Modus

Im Mock-Modus (BUNKERBOX_MOCK=1) simuliert Bunkerbox die Beispiel-Hardware: eine 240-GB-Systemplatte, 2 × 16 TB HDD und 5 × 5 TB HDD im Pool tank (Mirror + RAIDZ1), 2 × 1 TB SSD im Pool apps (Mirror), zwei neue, freie 18-TB-HDDs (sdk, sdl) für den Burn-in mit den Datasets tank/media, tank/documents, tank/backup, tank/home und apps/appdata (/appdata), einigen Snapshots, Zeitplänen und 32 GiB RAM. Alle Aktionen funktionieren, ändern aber nur den simulierten Zustand; ein Scrub dauert 15 Minuten, ein Resilver 3 Minuten. Der simulierte Zustand beginnt bei jedem Start neu.

Ruhezustand (Spindown)

Der Reiter Ruhezustand listet alle drehenden Platten (HDD) außer der Systemplatte mit Verwendung, aktuellem Zustand (Aktiv, Leerlauf, Schläft), der Zeit ohne Zugriff und der eingestellten Leerlaufzeit. SSDs, NVMe-Platten und die Systemplatte werden nie abgeschaltet.

• Zustand ohne Aufwecken: Bunkerbox fragt den Zustand jede Minute mit smartctl -i -n standby ab (Ersatz: hdparm -C). Beide Befehle wecken eine schlafende Platte nicht; auch die SMART-Werte im Reiter Platten werden mit -n standby gelesen.
• Einstellen legt pro Platte fest, ob und nach wie vielen Minuten ohne Lese- oder Schreibzugriff sie abgeschaltet wird (5–720 Minuten), und mit welchem Verfahren:
  • Leerlaufüberwachung von Bunkerbox (Standard): Bunkerbox liest jede Minute die gelesenen und geschriebenen Sektoren aus /sys/block/<platte>/stat (SMART-Abfragen zählen dort nicht mit). Ändern sie sich für die eingestellte Zeit nicht, schickt Bunkerbox die Platte mit hdparm -y schlafen. Funktioniert mit den meisten Platten, auch an USB-Adaptern.
  • Timer der Platten-Firmware (hdparm -S): Die Platte schaltet sich selbst ab. Die Firmware kennt nur 5-Sekunden-Schritte bis 20 Minuten, 21 Minuten und darüber 30-Minuten-Schritte bis 5,5 Stunden; Bunkerbox rundet auf. Weil manche Platten den Wert nach einem Stromausfall vergessen, setzt Bunkerbox ihn beim Start und bei jedem erneuten Anschließen neu. Wird das Verfahren gewechselt oder der Ruhezustand ausgeschaltet, setzt Bunkerbox den Timer auf 0 zurück.
• Jetzt abschalten schickt eine Platte sofort schlafen (hdparm -y). Sie wacht beim nächsten Zugriff automatisch wieder auf; das dauert einige Sekunden.
• Nie während Scrub, Resilver oder Burn-in: Läuft auf dem Pool einer Platte ein Scrub oder Resilver oder auf der Platte ein Burn-in, schaltet Bunkerbox sie nicht ab und verweigert Jetzt abschalten; die Tabelle zeigt den Grund. Ein Firmware-Timer greift in dieser Zeit ohnehin nicht, weil die Platte ständig gelesen wird.
• Die Einstellungen liegen in data/spindown-state.json (600) unter der stabilen Platten-ID (/dev/disk/by-id); sie gelten also auch, wenn sich der Kernelname (sdb) ändert. Der Reiter Platten zeigt den Zustand ebenfalls an.

Tipp: Häufiges Anlaufen verschleißt Platten. Für Pools mit regelmäßigen Zugriffen (Apps, Datenbanken) besser keinen Ruhezustand verwenden; für Archiv-Pools sind 20–60 Minuten üblich.

Einbrennen (Burn-in)

Neue Platten fallen am häufigsten in den ersten Betriebswochen aus. Der Reiter Burn-in prüft neue Platten deshalb gründlich, bevor sie in einen Pool kommen. Angeboten werden nur freie Platten (kein Pool, keine Partitionen oder Dateisysteme), nie die Systemplatte; der Dienst prüft das auch selbst.

Ein Burn-in besteht aus drei Tests, die einzeln abgewählt werden können:

Test	Befehl	Dauer (18 TB)
SMART-Kurztest	smartctl -t short	etwa 2 Minuten
Schreibtest	badblocks -w -s -v (vier Muster 0xaa, 0x55, 0xff, 0x00, jedes geschrieben und zurückgelesen)	mehrere Tage
SMART-Langtest	smartctl -t long	ein bis zwei Tage

• Starten: Burn-in starten zeigt Modell, Seriennummer, Größe und by-id-Pfad. Zur Bestätigung wird die Seriennummer der Platte eingetippt. Der Schreibtest löscht alle Daten der Platte unwiderruflich.
• Sicherheit: Unmittelbar vor dem Schreibtest prüft Bunkerbox noch einmal, dass unter dem Pfad dieselbe Platte (Seriennummer und Größe) hängt, dass sie weiterhin frei ist und dass dort kein badblocks läuft. Geschrieben wird über den /dev/disk/by-id-Pfad. Platten mit laufendem Burn-in werden von Pool anlegen, vdev hinzufügen und Platte ersetzen abgelehnt und nie abgeschaltet. Platten über 16 TiB testet badblocks mit 8-KiB-Blöcken, weil es nur 2³² Blöcke zählen kann.
• Fortschritt: Laufende Burn-ins erscheinen als Karte mit Gesamtfortschritt, dem Fortschritt jedes Tests (Durchgang n von 8 beim Schreibtest), den bisher gefundenen defekten Blöcken und dem voraussichtlichen Ende. Protokoll zeigt die Befehle, Phasenwechsel, defekte Blöcke und SMART-Änderungen. Mehrere Platten können gleichzeitig geprüft werden.
• Ergebnis: Vor und nach dem Burn-in liest Bunkerbox die SMART-Zähler (neu zugewiesene, ausstehende und nicht korrigierbare Sektoren, gemeldete Lesefehler, CRC-Fehler, bei NVMe Medienfehler). Durchgefallen ist eine Platte bei defekten Blöcken, gestiegenen Defektzählern, einem fehlgeschlagenen Selbsttest oder einem fehlerhaften SMART-Status. Steigen nur CRC- oder Timeout-Zähler, gilt sie als bestanden mit dem Hinweis, die Verkabelung zu prüfen. Schlägt ein Test fehl, werden die folgenden übersprungen. Lehnt die Platte einen SMART-Test ab (häufig bei USB-Adaptern), wird er übersprungen und der Burn-in nach den übrigen Tests bewertet.
• Eingebrannt: Nach einem bestandenen Burn-in trägt die Platte im Reiter Platten und im Pool-Assistenten die Markierung Eingebrannt, solange die Seriennummer übereinstimmt und kein späterer Burn-in durchgefallen ist. Der Assistent weist auf noch nicht eingebrannte Platten hin, verhindert ihre Verwendung aber nicht.
• Abbrechen beendet den laufenden Test (badblocks wird beendet, ein Selbsttest mit smartctl -X abgebrochen). Die Platte gilt dann nicht als eingebrannt.
• Verlauf: Die letzten 50 Burn-ins bleiben mit Ergebnis, Dauer, defekten Blöcken, SMART-Änderungen und Protokoll in data/burnin-history.json (600) erhalten. Wird Bunkerbox während eines Burn-ins neu gestartet, gilt dieser als unterbrochen (badblocks läuft nicht weiter).
• Updates werden zurückgehalten, solange ein Burn-in läuft (auch automatische Updates und update.sh).
• Benachrichtigung: Am Ende eines bestandenen oder durchgefallenen Burn-ins wird das Ereignis Burn-in beendet gemeldet (siehe Benachrichtigungen).

Im Mock-Modus dauert ein vollständiger Burn-in etwa vier Minuten; die zweite neue 18-TB-Platte (sdl) entwickelt dabei drei defekte Blöcke und fällt durch.