Veröffentlicht am 12.9.2026

Unsere Firmen-IT: Was wir selbst betreiben und warum

Viele kleine Betriebe kennen ihre IT nur als Sammlung von Logos: hier ein Datei-Dienst, dort ein Passwort-Tresor und irgendwo ein Server. Schwierig wird es, wenn eine Störung auftritt. Dann zählt nicht, wie viele Programme vorhanden sind, sondern wer verantwortlich ist, welche Daten wo liegen und wie das System wiederhergestellt wird.

Wir haben unsere eigene Firmen-IT deshalb bewusst in wenige Bausteine gegliedert. Einen großen Teil betreiben wir selbst, aber nicht alles. Selbstbetrieb ist für uns kein Glaubenssatz. Er ist eine Betriebsentscheidung, die nur sinnvoll ist, wenn Zuständigkeit, Aktualisierung und Wiederherstellung mitgedacht werden.

Unsere Systemkarte

Die folgende Übersicht zeigt die tatsächliche Aufteilung. Sie nennt absichtlich keine internen Hostnamen, Zugangspfade oder Geheimnisse.

Diese Karte verhindert eine bequeme, aber falsche Aussage: Nicht "alles" ist selbst gehostet. Unsere Homepage läuft auf Cloudflare, und E-Mails aus dem Kontaktprozess werden über Resend zugestellt. Auch externe Dienste brauchen bei uns einen Verantwortlichen, dokumentierte Einstellungen und einen Plan für Änderungen.

Warum wir diese Systeme selbst betreiben

Bei Dateien, Passwörtern und Entwicklung wollen wir Konten, Konfiguration und Datenflüsse selbst nachvollziehen können. Das erleichtert eine dokumentierte Übergabe und verhindert, dass nur eine Person die Anlage versteht. Open Source ist dabei ein Werkzeug, keine automatische Garantie für Sicherheit oder geringe Kosten.

Der Preis für Kontrolle ist Betriebsarbeit. Updates müssen geplant, Abhängigkeiten geprüft und Fehler beobachtet werden. Backups müssen das System verlassen, damit ein Defekt oder Bedienfehler am Ursprungsort nicht gleichzeitig die Sicherung trifft. Unsere Sicherungen werden deshalb verschlüsselt außerhalb der betriebenen Systeme aufbewahrt.

Die Konfiguration ist mit Ansible reproduzierbar. Die Docker-Dienste werden durch systemd verwaltet. Das bedeutet praktisch: Der gewünschte Zustand ist als Konfiguration beschrieben, und der Start der Dienste hängt nicht von einem handgeschriebenen Zettel ab. Trotzdem ersetzt Automatisierung keine Prüfung. Eine reproduzierbare Installation kann auch einen reproduzierbaren Fehler enthalten.

Für Änderungen empfiehlt sich deshalb eine kurze Vorabprüfung. Ist die Konfiguration nachvollziehbar versioniert? Betrifft die Änderung gespeicherte Daten oder nur den Dienst? Gibt es einen Rückweg, falls der Start fehlschlägt? Prüfen Sie danach nicht nur, ob ein Prozess läuft, sondern eine echte Kernfunktion: etwa Anmeldung, Dateiabruf oder Zugriff auf ein Projekt. Dieses Vorgehen verhindert, dass eine technisch "laufende" Anwendung mit kaputter Nutzerfunktion übersehen wird.

Was ein Restore-Test wirklich belegt

Am 16. Juli 2026 haben wir eine Nextcloud-Testinstanz zerstört und aus der Sicherung wiederhergestellt. Danach haben wir Anmeldung, Dateiliste und Download geprüft. Dieser Test belegt genau diesen Ablauf für diese Testinstanz zu diesem Zeitpunkt.

Er belegt nicht, dass jede denkbare Störung abgedeckt ist. Er ist auch kein Nachweis für einen produktiven Kunden-Rollout oder dafür, dass jeder unserer Dienste vollständig wiederhergestellt wurde. Gerade diese Grenze gehört in ein ehrliches Prüfprotokoll: getesteter Umfang, Ergebnis, offene Punkte und nächster Termin.

Für einen kleinen Betrieb ist ein enger, wiederholbarer Test oft wertvoller als ein großer Satz "Backup erfolgreich". Bei einer Dateiablage könnten die Prüfschritte so aussehen:

• Testumgebung aus aktueller Sicherung aufbauen
• mit einem vorgesehenen Testkonto anmelden
• Ordner und eine festgelegte Beispieldatei finden
• Datei herunterladen und öffnen
• benötigte Zeit und Abweichungen dokumentieren
• Testumgebung anschließend kontrolliert entfernen

Was sich im Betrieb ändern darf

Am 18. August 2026 haben wir auf unserer eigenen Homepage Google Analytics durch selbst betriebenes Umami ersetzt. Das ist eine konkrete Systementscheidung, aber kein Beweis dafür, dass dieselbe Lösung zu jedem Betrieb passt. Anforderungen an Auswertungen, vorhandene Integrationen, interner Aufwand und Verantwortlichkeiten unterscheiden sich.

Die bessere Frage lautet daher nicht "Cloud oder eigener Server?", sondern: Wer besitzt das Konto, wer kann administrieren, wer aktualisiert, wo liegt die Sicherung und wer kann sie nachweislich zurückspielen? Erst wenn diese fünf Antworten klar sind, wird aus Software belastbare Firmen-IT.

Diese Antworten gehören in eine kurze Betriebsdokumentation, die mehr als eine Person finden und verstehen kann. Ergänzen Sie je System einen fachlichen Eigentümer, einen technischen Verantwortlichen und eine Vertretung. Prüfen Sie die Karte nach jeder größeren Änderung und mindestens einmal im Jahr. So bleibt sie ein Arbeitsmittel statt einer Momentaufnahme.

Für die erste eigene Karte reichen 30 Minuten: Listen Sie die fünf wichtigsten Arbeitsmittel auf, ergänzen Sie Betreiber und Administrator und markieren Sie jede unbekannte Antwort. Beginnen Sie anschließend mit dem System, dessen Ausfall den Arbeitstag am stärksten behindern würde. So entsteht eine priorisierte Aufgabenliste.

Wenn Sie Ihre Systemlandschaft ebenso klar ordnen möchten, finden Sie unter IT-Infrastruktur unsere Leistungen für Einrichtung, Restore-Nachweis und laufenden Betrieb.