Jeder kennt es, viele nutzen es, einige hassen es: Excel. Oder fairerweise auch LibreOffice Calc und andere Open-Source-Bürolösungen. Im Bereich des Self-Hostings sind diese Tabellen höchstens eine prall gefüllte, zu sichernde Datei auf einem Fileserver. Aber das war’s dann auch schon.
Ich nutze Tabellenkalkulationen seit 2001 beruflich. Auch in meiner aktuellen Selbstständigkeit komme ich zurzeit noch nicht ganz ohne aus. Das Werkzeug erlaubt es, in jede Zelle zu schreiben, was man möchte: Kontaktdaten, Lagerbestand, Margen-Rechnungen, verschachtelte Formelsammlungen, die nur noch Eingeweihte lesen können.
Solche Listen wachsen und gedeihen. Und wenn man nicht aufpasst – oder der Urheber komplexer Tabellen die Firma verlässt – bricht die ganze Kiste im schlimmsten Fall zusammen.
Für Flexibilität ist Excel perfekt. Für Sicherheit, Datenschutz und Wartung ist es eine Katastrophe.
Das beginnt schon beim Schutz: Jede(r) kann diese Tabellen öffnen, maximal durch ein einziges Haupt-Passwort gesichert. Die letzte Zeile enthält noch die gültige Formel, wird aber oft überschrieben oder beim Kopieren kaputt gemacht. Die Funktion ist dann hinüber, kaum noch auf weitere Zeilen „heil“ übertragbar.
Zwei Tabellen zu verknüpfen und Daten abzugleichen, kann eine enorme Serverlast erzeugen. Vollgestopfte Tabellen, die einfach nur weiter nach unten wachsen, ohne alte Zeilen in ein Archiv auszulagern, werden zur Performance-Hölle – nicht nur auf älteren PCs.
Und das sage ich als jemand, der sich selbst gerne als Excel-Guru bezeichnet. Ich kenne die Fallstricke, kann die Tools sauber einrichten, sodass sie selten Probleme machen (meist war es dann ein Bedienfehler, sorry Leute 🙂 ). Aber in jeder Firma, in der ich ein Excel-Audit durchführen durfte, standen mir die Haare zu Berge.
Anders sind da Datenbanken
Auch wenn ich seit 10 Jahren mit WordPress arbeite – einem Content-Management-System für Webseiten – kam ich hier noch nie in die Verlegenheit, irgendetwas an der dahinterliegenden Datenbank in der Sprache SQL ändern zu müssen.
Und da sind wir beim Kernunterschied angelangt.
Strukturierte vs. unstrukturierte Daten
Von unstrukturierten Daten spricht man bei allerlei Dateiformaten, die irgendwie auf der Festplatte abgelegt sind: PDFs, Logfiles, Bilder, Excel-Tabellen. Sicher, eine Ordnerstruktur ist hilfreich, aber die Daten selbst haben keine feste Form.
Wer im Self-Hosting unterwegs ist (und darauf zielt dieser Blog ja ab), findet sich schnell in der Welt der strukturierten Daten wieder. Sei es ein CRM, ein Kanban-Board, ein DMS oder ein Bilderserver: All dies sind Web-Apps. Neben dem Interface läuft in der Regel eine Datenbank. Meistens SQL-Datenbanken.
Der Unterschied zu Excel ist fundamental:
- Excel: Es ist egal, was in welcher Zelle steht.
- Datenbank: Jede Spalte hat einen festen Datentyp. Ein Typ pro Spalte.
Eine Datenbank ist zwar auch eine Tabelle, aber eine relationelle, vielschichtige. Erst dadurch lassen sich Daten sinnvoll verknüpfen. Dazu kommen feine Zugriffsrechte: Benutzer A darf alle Spalten sehen, Benutzer B nur Spalte XYZ. In einer Personaldatenbank etwa darf der HR-Mitarbeiter das Gehalt sehen, der normale User nicht.
Wird eine Zeile erreicht, gibt es keine „fehlenden Formeln“. Pro Datensatz wird jede Spalte einfach nach unten verlängert – immer mit dem gleichen Inhaltstyp, denselben Berechtigungen und Funktionen.
Mit SQL-Abfragen wird dann ein Schuh draus: Die Datenbank liefert eine Menge gut sortierter Daten aufbereitet. In Excel ist das nicht der Fall. Im Warenwirtschaftssystem liegen Bestellungen in Tabelle A, Kundendaten in Tabelle B und Zahlungsdaten in Tabelle C. Diese zu einem Gesamtbild zusammenzubauen, ist die Aufgabe der Abfrage.
Du wirst im Self-Hosting also mit vielen Datenbanken zu tun bekommen. Auch wenn du nach der Einrichtung einer Web-App nie wieder SQL tippen musst: Du solltest verstehen, was in so einer Datenbank passiert. Es ist nicht nur sture Datenablage.
Was Facebook mit 25 TB anstellt
Nun widmen wir uns einem alten Bekannten: Facebook.
Dort fallen aktuell rund 25 Terabyte pro Woche nur an neu hochgeladenen Bildern an. Klingt vielleicht nicht nach viel, wenn man an drei Milliarden Nutzer denkt. Aber Facebook komprimiert die Bilder schon beim Upload, und ein Jahr hat 52 Wochen.
Rechnen wir kurz: 1.300 Terabyte pro Jahr – nur an Bildern. Dazu kommen Reels, Videos, Kommentare und mehrere Gigabyte Hass und Hetze. Da sammelt sich gewaltig was an. Mit normalen Festplatten und Verzeichnisstrukturen ist das nicht mehr zu handhaben.
Eine normale Verzeichnisstruktur wie unter Windows oder Linux (z. B. /Download/inhalt/bild.jpg) stößt hier sehr schnell an seine Grenzen. Die Dateisysteme werden langsam, die Metadaten explodieren.
Hier benötigt es eine andere Lösung: Der Objektspeicher (Object Storage).
Objektspeicher: Kein Dateibaum, sondern ein flacher Raum
Ein Objektspeicher kommt ohne Dateibaum aus. Er ist ein flacher Raum, in dem jedes Objekt eine eindeutige ID hat. Dafür ist jedes Objekt mit mehr Metadaten angereichert, als normale Dateien zulassen würden. Diese Metadaten umfassen zum Beispiel „wer hat das Bild hochgeladen“, „zu welchem Projekt gehört das“, „Wer darf es sehen“, „wie lange muss das aufbewahrt werden“.
Der Zugriff erfolgt nicht mehr über einen Dateimanager oder Kommandozeilen-Befehle (ls, cp), sondern über eine API (Schnittstelle). Und wenn der Speicher voll ist, können einfach neue Knoten hinzugefügt werden, ohne die Struktur zu ändern.
Objektspeicher gelten als die Speicherlösung der Zukunft. Das zielt zwar oft auf große Anbieter ab, die diesen Speicher verkaufen wollen, aber das Prinzip ist universell. Ich habe mir selbst einen externen Objektspeicher bei einem deutschen Hoster zugelegt – als letzte Instanz der Sicherheit, falls hier alle Sicherungssysteme versagen (z. B. durch einen Brand).
Self-Hosting von Objektspeicher: Die harte Realität
Doch nun zur knallharten Wahrheit für alle, die selbst hosten wollen.
Objektspeicher im S3-Typ (wie bei Amazon) sind erst ab drei Knoten wirklich sinnvoll, da sie Redundanz erfordern. Ein Single-Node-Objektspeicher ist mangels Redundanz für produktive Systeme ziemlich witzlos.
Weiterhin ist mindestens eine 10-Gbit/s-Infrastruktur erforderlich. Ein 1-Gbit/s-Netzwerk wäre ein massiver Flaschenhals, und dann macht das Ganze keinen Spaß mehr.
Die Wahrheit ist: Eine Festplatte zu partitionieren ist erheblich einfacher, selbst wenn zwei Betriebssysteme parallel laufen sollen. Es ist kein „Installieren und Loslegen“. Du bist nicht einfach nur der Admin eines Objektspeichers – du wirst zum Architekten der ganzen Infrastruktur.
Deine Tools sind dann Ceph oder MiniO. Die findet man leicht im Netz, aber die Einrichtung ist kein Anfängerprojekt.
Was wird also tatsächlich benötigt?
Für die Setups, mit denen wir uns im Self-Hosting befassen – und sei dieser noch so komplex – sind in der Regel Single-Node-Server völlig ausreichend, gepaart mit einer soliden Backup-Strategie.
- Für Nextcloud oder Tools wie CRM ist ein spezialisiertes Dateisystem wie ZFS oft die bessere Wahl als ein Ceph-Cluster.
- Für Übungen, die einen Objektspeicher benötigen, ist MiniO der perfekte Einstieg.
Und keine Angst vor Datenbanken: Für professionelle Umgebungen führen viele Wege weg von Excel und Ähnlichem, hin zu strukturierten Datenbanken. Das bedeutet nicht, dass Excel überflüssig wird – das ist es nicht und wird es auch nicht sein. Aber der Weg kann in vielen Anwendungsfällen hin zu echten Datenbank-Systemen (wie PostgreSQL) und Tools wie Metabase führen, die diese Daten sicher verwalten und visualisieren. Der Aufwand, diese einmalig aufzustellen, ist nicht viel größer als bei einem komplexen Excel-Projekt. Und es ist einfach sicherer.
Aktuelle Objektspeicher wie S3 sind zwar oft bei US-Dienstleistern gehostet. Aber auch hier hilft das Umsehen auf dem deutschen oder EU-Markt, um diese Abhängigkeit gar nicht erst einzugehen oder zu reduzieren. Es gibt kein Muss, diese Dienste zu nutzen. Man muss sich nur die Alternativen suchen.
Auch Google mischt natürlich mit
Das wundert ja beinahe nicht an dieser Stelle: Auch Google mischt in diesem Bereich natürlich mit: Firebase ist Das wundert an dieser Stelle kaum: Auch Google mischt in diesem Bereich mit. Firebase ist eine BaaS-Plattform (Backend as a Service), die vorgefertigte Dienste für Entwickler bietet. Diese Suite ist bewusst extrem einfach gehalten, um schnelle Prototypen zu ermöglichen und Startups anzusprechen, die Zeit sparen wollen. Hier kommt wieder die bekannte Logik zum Tragen: Mit möglichst wenig Hürden möglichst viel Traffic und Umsatz in Richtung Google lenken. Das ist per se erst einmal kein bisschen verwerflich; jedes Unternehmen sollte umsatzorientiert arbeiten.
Allerdings bringt die Architektur der Suite kritische Punkte mit sich:
- Statisches Hosting mit globaler CDN-Verteilung
- Analytics und Crashlytics – Tracking und Fehlerübermittlung
- Closed Source – die Backend-Logik liegt nicht offen
- Vendor Lock-in – einmal tief in Google Ökosystem verwoben, ist ein Wechsel später extrem aufwendig
Es gäbe noch weitere Punkte, aber diese hier sind aus Sicht des US Cloud Act und der Sicherheit deiner Daten bereits völlig ausreichend.
Ich habe die Umstellung auf ein selbst gehostetes Warenwirtschaftssystem verwerfen müssen, weil dieses auf Firebase aufbaute. Dies sollte für Datenschutzbewusste und im Kontext der Datensouveränität eine der ersten Fragen bei WebApps auf dem eigenen Server sein.
Mit Superbase steht aus dem OpenSource Bereich eine vernünftige Alternative zu Firebase bereit. Diese arbeitet jedoch nicht als NoSQL Datenbank, sondern ist PostgreSQL basiert. Ich denke, das ist aber in ganz ferner Zukunft für dich als Leser dieses Beitrags – zumal sich keinzugriff.de mehr mit fertigen WebApps/MicroApps befasst und nicht mit dem Aufbau eigener Apps.
Fazit: Vom Zellentableau zum bewussten Datenmanagement
Der Weg von der simplen Excel-Tabelle zu strukturierten Datenbanken oder Objektspeichern ist kein technischer Zwang, sondern ein dringender Ratschlag für alle, die ihre Daten langfristig souverän halten wollen. Excel ist flexibel und für schnelle Listen unschlagbar. Aber sobald es um Sicherheit, Konsistenz und Skalierung geht, stößt es an seine Grenzen. Es ist nicht die „Willkür“ des Nutzers, sondern die technische Realität: Tabellen können keine Beziehungen abbilden, keine feinen Rechte vergeben und wachsen nur bedingt mit den Daten.
Datenbanken und Objektspeicher sind keine Pflicht für jeden Self-Hoster. Wer eine kleine Nextcloud auf dem Raspi betreibt, kommt mit einem soliden Dateisystem oft vollkommen aus. Aber es ist wichtig zu wissen, dass es noch eine Ebene tiefer geht. Dass es Konzepte gibt, bei denen Daten nicht nur gespeichert, sondern intelligent verwaltet werden – mit Metadaten, Relationen und API-Zugriffen.
Die Technologien wie Ceph oder MiniO sind für die meisten Heimanwender mit einem einzigen Server und drei Festplatten tatsächlich überdimensioniert. Der Aufwand für ein redundantes Drei-Knoten-Cluster mit 10-Gbit-Netzwerk ist enorm und für die private Nutzung oft nicht gerechtfertigt. Dennoch lohnt es sich, diese Begriffe und Konzepte einmal gehört zu haben. Sie zeigen, wie professionelle Umgebungen mit Daten umgehen und warum die Abhängigkeit von US-Cloud-Diensten oft nicht an der Technik, sondern am fehlenden Verständnis der Alternativen liegt.
Die Entscheidung liegt bei dir: Bleibst du bei bewährten, einfachen Methoden wie Excel, solange sie funktionieren? Oder tauchst du tiefer ein, um die Prinzipien zu verstehen, die auch große Systeme wie Facebook antreiben? Es gibt kein „richtig“ oder „falsch“, aber wer die Grundlagen kennt, trifft bessere Entscheidungen für seine eigene Infrastruktur. Und das ist der erste Schritt zu echter Datensouveränität.
Thinkin ‚bout
