TrueNAS Spotlight: Volltextsuche und Search Index im NAS

Eine der Kernfunktionen, die viele Nutzerinnen und Nutzer von ihrem Desktop-Betriebssystem gewohnt sind, fehlt in klassischen NAS-Systemen bislang fast komplett: die schnelle Volltextsuche über Dateiinhalte. Wer eine Rechnung aus dem letzten Quartal sucht und nur eine Vertragsnummer im Kopf hat, durchforstet meist Hunderte PDFs manuell oder behilft sich mit lokalen Tools wie Everything, Recoll oder DocFetcher. Mit TrueNAS 26.04 ändert sich das: Das Release bringt einen integrierten Search Index mit Volltextsuche über Dateinamen und Inhalte — und macht das NAS zur durchsuchbaren Wissensbasis. Im T3 Podcast E041 hat iXsystems die Funktion vorgestellt; hier die Einordnung aus DATAZONE-Praxis.

Was kann der Search Index?

Der Search Index ist ein optionaler Dienst, der pro Pool oder pro Dataset aktiviert wird. Einmal eingeschaltet, indiziert er im Hintergrund:

• Dateinamen und Pfade — wie bisher, nur strukturiert und durchsuchbar
• Metadaten — Erstellungs- und Änderungsdatum, Besitzer, Dateigröße, Berechtigungen
• Inhalte von Office-Dokumenten (docx, xlsx, pptx, odt, ods, odp), PDFs (text-basiert und über OCR), Klartext-Dateien (txt, md, csv, log, json, yaml, xml) sowie E-Mail-Mailboxen (eml, mbox)

Gesucht wird über die TrueNAS-Web-UI oder per REST-/WebSocket-API — Letzteres öffnet die Tür für Integrationen mit DMS-Systemen, RAG-Pipelines und Helpdesk-Tools.

Architektur: Apache Tika plus Lucene

Unter der Haube setzt TrueNAS auf etablierte Open-Source-Komponenten:

Komponente	Aufgabe
Apache Tika	Content-Extraction aus über 1.000 Dateiformaten
Apache Lucene	Invertierter Index für schnelle Textsuche
Tesseract OCR (optional)	Texterkennung in gescannten PDFs und Bildern
TrueNAS-Indexer-Service	Orchestrierung, Inkrementeller Index, Re-Indexing nach Snapshot-Rollback

Apache Tika ist seit Jahren der De-facto-Standard für Content-Extraction in der Java-Welt — Elasticsearch, Solr und etliche kommerzielle DMS-Lösungen bauen darauf auf. Lucene ist die darunterliegende Such-Engine derselben Apache-Familie. Beide sind bewusst nicht selbst erfunden, sondern in den TrueNAS-Stack integriert. Das hat einen pragmatischen Grund: Die Wartung eines eigenen Index-Stacks wäre für iXsystems weder sinnvoll noch leistbar.

Wie der Index aktualisiert wird

Der Indexer arbeitet inkrementell und nutzt die ZFS-eigenen Informationen über geänderte Dateien:

1. Erst-Indizierung: Voller Scan aller indizierten Datasets — typischerweise Stunden bis Tage je nach Datenmenge
2. Inkrementeller Update: Über inotify-Watcher und periodische ZFS-Diff-Checks werden geänderte Dateien sofort oder im 5-Minuten-Intervall nachindiziert
3. Snapshot-Awareness: Nach einem Snapshot-Rollback wird der Index automatisch konsolidiert — keine inkonsistenten Suchergebnisse
4. Replikation-Awareness: Auf Replikationszielen wird der Index optional mit-aufgebaut, sodass das Backup-NAS ebenfalls durchsuchbar ist

Der Index selbst liegt in einem separaten Dataset (.truenas-search-index), das automatisch komprimiert und vom Snapshot-Schedule ausgenommen wird. Die typische Index-Größe liegt bei 2–5 % der indizierten Nutzdaten — bei 100 TB indizierten Office-Dokumenten also rund 2–5 TB Index. Wer das nicht möchte, kann den Index auf einen separaten, schnellen Pool legen (NVMe-SSD-Special-VDEV bietet sich an).

Use-Cases aus der Praxis

1. Steuerberatung und Buchhaltung

Der Klassiker. Mandantin fragt nach einer Rechnung aus 2024-12 mit einem bestimmten Betrag. Statt durch Mandantenordner zu klicken, gibt der Sachbearbeiter "Rechnung 2024-12" "Beratungsleistung" 1.785 ein und findet die PDF in Sekunden — egal in welchem Mandanten-Verzeichnis sie liegt. Voraussetzung: Die Mandantenrechte werden eingehalten, dazu unten mehr.

2. Anwaltskanzlei

“Wo ist nochmal der Vertrag mit Mandant X aus Q2 2023, bei dem es um die Wettbewerbsverbots-Klausel ging?” — vorher: Mandantenakte heraussuchen, dort Verträge sichten, manuell scrollen. Mit Search Index: Volltextsuche nach Mandantenname und Begriff, fertige Trefferliste in Sekunden.

3. Engineering und Konstruktion

CAD-Files selbst werden nicht indiziert (Tika kennt die proprietären Formate nur teilweise), aber Begleit-Dokumente, Stücklisten als XLSX, Anforderungs-PDFs und Markdown-Spezifikationen sind durchsuchbar. Praktisch, wenn ein Bauteil in mehreren Projekten vorkommt.

4. Helpdesk und Wissensmanagement

Wenn das gesamte Wissensmanagement bisher in einem Sammelordner mit Word-Dateien liegt (Realität in vielen KMU!), wird der Sammelordner mit dem Search Index zur durchsuchbaren Wissensbasis — ohne Migration in Confluence oder ein DMS.

5. RAG-Vorbereitung

Für alle, die mit Retrieval Augmented Generation experimentieren: Der TrueNAS-Index liefert über die API direkt Text-Snippets samt Metadaten — also genau das, was ein RAG-System als Quelle braucht.

Ressourcen-Bedarf realistisch eingeordnet

Volltextsuche kostet CPU, RAM und IOPS. iXsystems gibt im T3-Podcast folgende Richtwerte:

Aspekt	Erst-Indizierung	Steady-State
CPU	Mittel bis hoch (4–8 Kerne empfohlen)	Niedrig (<10 %)
RAM	+8–16 GB ARC zusätzlich	+4–8 GB Lucene-Heap
IOPS	Sequentieller Read mit hoher Bandbreite	Niedrig, schreibend punktuell
Index-Storage	2–5 % der Nutzdaten	Wächst linear mit Datenwachstum

Auf einer TrueNAS Mini X+ mit 64 GB RAM lässt sich der Index für ein moderates Dataset sinnvoll betreiben. Bei Datenmengen jenseits von 50 TB und gleichzeitigem hohen Such-Aufkommen empfehlen wir mindestens eine H-Serie oder größer — schon allein, weil OCR (wenn aktiv) sehr CPU-hungrig ist.

Datenschutz: Rechte werden respektiert

Eine berechtigte Frage: “Findet jeder Nutzer jetzt jede Datei im NAS?” Antwort: Nein. Der TrueNAS-Indexer arbeitet zweistufig:

1. Index global: Alle indizierten Dateien stehen im Lucene-Index — unabhängig von Benutzerrechten
2. Filter pro Suche: Bei jeder Suchanfrage werden die Treffer vor der Anzeige gegen die SMB- bzw. NFS-Berechtigungen des suchenden Users gefiltert

Das ist technisch identisch zu dem, was Windows Search im Active-Directory-Umfeld macht. Wichtig zu wissen: Der Index selbst enthält den extrahierten Klartext — wer direkt auf den Index-Speicher zugreifen kann (also als Admin), sieht alles. Für hochsensible Datenbereiche (Personalakten, Forschungsdaten unter NDA) sollte der Search Index daher gezielt nicht aktiviert werden, oder das entsprechende Dataset vom Index ausgenommen werden.

Was der Search Index nicht ist

Realistische Erwartungshaltung:

• Kein Volltext-DMS: Es gibt keine Versionierung, keine Workflows, keine Annotationen. Wer Dokumentenmanagement im engeren Sinn braucht, kommt um ein DMS wie ELO, M-Files oder ecoDMS nicht herum.
• Keine semantische Suche: Lucene macht Keyword-Matching mit Stemming und Synonymen. “Vertrag” findet “Verträge”, aber nicht “Kooperationsvereinbarung”. Eine semantische Vektor-Suche steht laut iXsystems auf der Roadmap, ist aber zum Release 26.04 nicht enthalten.
• Keine Bild-Suche: OCR macht Text aus Bildern lesbar, aber Bildinhalte selbst (Logos, Personen, Szenen) sind nicht durchsuchbar.
• Kein Ersatz für strukturierte Datenbanken: Wer Rechnungspositionen mit Steuersatz und Betrag strukturiert abfragen will, braucht weiterhin ein Buchhaltungs- oder ERP-System.

Aktivierung in der Praxis

Im TrueNAS-WebUI unter Datasets → [Dataset] → Edit → Indexing:

1. Enable Search Index aktivieren
2. Index Content einschalten (sonst werden nur Dateinamen indiziert)
3. OCR for scanned PDFs — nur aktivieren, wenn CPU-Kapazität da ist
4. Index Location: separater Pool empfohlen für große Datenmengen
5. Excluded Patterns: z.B. *.iso, *.vmdk, */backups/*

Anschließend Save — die Erst-Indizierung läuft im Hintergrund mit niedriger Priorität an. Der Fortschritt ist im Reporting → Search Index sichtbar.

DATAZONE-Empfehlung

Volltextsuche im NAS ist eines der Features, bei denen Anwender nach einer Woche nicht mehr verstehen, wie sie ohne gearbeitet haben. Unser pragmatischer Rat:

• Sofort aktivieren für klassische Office-Datasets (Buchhaltung, Verträge, allgemeine Ablage)
• Nicht aktivieren für Backup-Datasets, ISO-Repositories und reine Media-Storages — bringt nichts und kostet Ressourcen
• Separat prüfen für Personalakten, Mandantengeheimnis-relevante Datasets und Forschungsdaten unter NDA — hier ggf. bewusst nicht indizieren oder eigene Pool-Topologie wählen
• Ressourcen vorher planen: Wer einen Mini X+ am Limit fährt, sollte vor der Indexierung Pool- und RAM-Headroom prüfen

Verwandte Artikel:

• TrueNAS-Konfigurator: Modell-Auswahl mit Live-Kapazitätsberechnung
• TrueNAS 25.10 Goldeye Release
• TrueNAS Snapshots und Replikation

Wer den Search Index für seinen Use-Case prüfen will, bekommt von uns gerne eine Einschätzung — inklusive realistischer Index-Größenabschätzung anhand der bestehenden Datasets.

Quellen

• TrueNAS 26.04 Release Notes (offizielle Dokumentation)
• T3 Podcast E041 — Search Index Walkthrough
• Apache Tika Project
• Apache Lucene