Das Synology Heimserver-Projekt · Band 2
Dein Heimserver läuft. Jetzt willst Du ihm vertrauen können.
Infrastruktur, Monitoring und Datenbanken: Wie aus einzelnen Diensten ein Aufbau wird, den Du verstehen, überwachen und weiterentwickeln kannst.
Ein grüner Container. Ein roter Monitor. Eine verschwundene Serveranzeige. Band 2 folgt den Fragen hinter diesen Momenten – mit konkreten Beobachtungen aus dem Projekt.
Der Weg durch Band 2
Fünf Kapitel. Eine Umgebung, die zusammenpasst.
- B2K1
Infrastrukturplanung
Rollen verteilen, Daten ordnen und den Ausbau vorbereiten.
- B2K2
Monitoring und Infrastruktur
Erkennen, was ein grüner oder roter Status tatsächlich aussagt.
- B2K3
MariaDB
Dauerhafte Daten, getrennte Zugänge und die Frage nach der Sicherung.
- B2K4
PostgreSQL
Eine zweite Datenbank – und eine verschwundene Serveranzeige.
- B2K5
Adminer und pgAdmin
Datenbanken verwalten und Verbindungen gezielt prüfen.
01 · Infrastrukturplanung
Bevor der nächste Container startet.
Der erste Dienst läuft. Dann kommt ein zweiter hinzu, eine Datenbank, eine Verwaltungsoberfläche, ein Monitor. Doch wo liegen ihre Daten? Welches NAS übernimmt welche Aufgabe? Und lässt sich dieser Aufbau in einigen Monaten noch erklären?
Eine stabile Heimserver-Infrastruktur beginnt nicht mit dem ersten Container. Sie beginnt mit einer klaren Vorstellung davon, welche Aufgabe jedes System übernimmt, wo Daten gespeichert werden und wie Dienste später sicher miteinander kommunizieren.
Band 2 beginnt mit diesen Entscheidungen. Im Projekt übernimmt die DS718+ Aufgaben der Verwaltung, während die DS920+ für Daten und Medien vorgesehen ist. Ordner, Compose-Dateien und gemeinsame Netzwerke erhalten eine erkennbare Ordnung. So bekommt der weitere Ausbau einen Platz, bevor neue Dienste hinzukommen.
Ohne gemeinsame Struktur entstehen mit der Zeit mehrere kleine Einzellösungen. Jede davon kann funktionieren, doch zusammen werden sie schwer zu warten. Die eigentliche Herausforderung ist daher nicht die Installation eines Programms. Sie besteht darin, eine Umgebung zu schaffen, in der neue Dienste nach denselben Regeln ergänzt, geprüft und später wiederhergestellt werden können.
Diese Trennung ist keine vollständige Hochverfügbarkeit. Sie ist aber ein sinnvoller erster Schritt: Kontrolle und Nutzdaten liegen nicht unnötig auf demselben System.
Warum gehören nicht alle Dienste in dieselbe Compose-Datei? Welche Daten müssen einen Containerwechsel überstehen? Das Kapitel macht aus diesen Fragen einen konkreten Aufbau – und zeigt, warum Ordnung später bei der Fehlersuche Zeit spart.
02 · Monitoring und Infrastruktur
Alles grün. Aber funktioniert es auch?
Du öffnest die Containerübersicht: alles läuft. Trotzdem lädt eine Webseite nicht. An dieser Stelle beginnt die eigentliche Überwachung. Sie muss mehr erkennen als einen gestarteten Prozess.
Ein Heimserver ist nicht schon deshalb zuverlässig, weil seine Container gerade laufen. Zuverlässigkeit entsteht erst dann, wenn Du erkennst, ob ein Dienst erreichbar ist, wann er ausgefallen ist und an welcher Stelle Du mit der Fehlersuche beginnen musst.
Container Manager und Portainer zeigen Dir, ob ein Container gestartet wurde. Das ist wichtig, beantwortet aber nur die erste Frage. Ein grüner Status bedeutet nicht automatisch, dass die Anwendung im Browser erreichbar ist oder ihre Aufgabe erfüllt.
Mit Uptime Kuma wird aus einem allgemeinen „erreichbar“ eine gezielte Frage: Antwortet das Gerät, der Port oder die erwartete Webseite? Und prüfst Du gerade den internen Dienst oder den Weg über Domain und Reverse Proxy? Dieselbe Anwendung kann bei diesen Prüfungen unterschiedliche Ergebnisse liefern.
Ein roter Monitor beweist zunächst nur, dass genau das eingetragene Prüfziel fehlgeschlagen ist. Er beweist nicht automatisch einen Ausfall des überwachten Systems.
Im Projekt wird eine rote Anzeige zum Anlass, das Prüfziel genauer anzusehen. Ist der Dienst ausgefallen – oder sucht die Überwachung noch am alten Anschluss? Das vollständige Kapitel verfolgt solche Spuren und zeigt, wie Du Messung und tatsächlichen Fehler auseinanderhältst.
03 · MariaDB
Der Container ist austauschbar. Deine Daten nicht.
Eine Datenbankinstallation dauert manchmal nur wenige Minuten. Das Vertrauen in sie entsteht später: wenn die Daten nach einem Neustart wieder da sind, Anwendungen nur ihre vorgesehenen Rechte erhalten und eine Sicherung mehr ist als ein beruhigender Dateiname.
Eine Datenbank ist kein gewöhnlicher Container. Das Programm lässt sich zwar schnell starten, doch die wertvollen Inhalte liegen außerhalb des Images. Passwörter müssen geschützt, Daten dauerhaft gespeichert und Zugriffe kontrolliert werden. Erst wenn diese Punkte zusammenpassen, entsteht aus einem gestarteten Container ein verlässlicher Datenbankdienst.
Das Kapitel führt MariaDB als eigenen Dienst ein. Es verbindet dauerhafte Datenverzeichnisse mit geschützten Zugangsdaten und getrennten Aufgaben für Administration und Anwendungen. Die Oberfläche zur Verwaltung bleibt ein eigener Baustein.
Die Trennung ist bewusst gewählt. Der Datenbankserver soll auch dann weiterlaufen, wenn eine Verwaltungsoberfläche neu gestartet oder aktualisiert wird. Ebenso darf ein Fehler in Adminer nicht automatisch die Datenbankdaten gefährden.
Im geprüften Aufbau war `projekt_test.sql` auf beiden NAS-Systemen vorhanden. Eine vorhandene Datei ist der erste Kontrollpunkt, aber noch kein vollständiger Wiederherstellungstest.
Eine SQL-Datei liegt bereit. Was weißt Du damit schon – und welche entscheidende Frage ist noch offen? Band 2 begleitet den Weg vom ersten Test bis zu den Kontrollen, auf die es beim späteren Wiederherstellen ankommt.
04 · PostgreSQL
Die Anmeldung klappt. Die Datenbank scheint verschwunden.
Mit PostgreSQL kommt eine zweite Datenbank ins Projekt. Du lernst den Dienst kennen, arbeitest mit dem Kommandozeilenwerkzeug psql und unterscheidest den Datenbankserver von seiner Verwaltungsoberfläche. Genau diese Unterscheidung wird plötzlich entscheidend.
Die Anmeldung an pgAdmin mit dem vorgesehenen Benutzer admin@example.com funktionierte. Doch in der linken Serverübersicht klaffte plötzlich eine Lücke: Die bekannte Registrierung „Postgresql“ war verschwunden. Für einen Einsteiger wirkt das wie ein kleiner Datenbank-Krimi. Wurde PostgreSQL gelöscht? Ist der Container abgestürzt? Sind sogar die Daten weg? MCP bremst an dieser Stelle den vorschnellen Alarm: Eine leere Anzeige ist noch kein Beweis. Erst werden Spuren gesichert, dann wird gehandelt.
Der Zugang zu pgAdmin funktioniert. Nur der vertraute Servereintrag fehlt. Jetzt wäre es verlockend, den Container neu anzulegen. Aber was, wenn die Datenbank die ganze Zeit erreichbar ist und die Spur in eine ganz andere Richtung führt?
Das Kapitel trennt Anzeige, Anmeldung und Datenbankzustand Schritt für Schritt. Welche Beobachtung den Ausschlag gibt und wie die Registrierung wieder auftaucht, erfährst Du in der vollständigen Fassung. Der Fall zeigt, warum eine kleine Lücke in einer Oberfläche eine große Fehlersuche auslösen kann.
05 · Adminer und pgAdmin
Die Anmeldeseite ist erst der Anfang.
Im Browser erscheint ein Login. Ein guter Anfang – aber noch kein Nachweis, dass Du die gewünschte Datenbank verwalten kannst. Zwischen Oberfläche und Datenbank liegt eine eigene Verbindung mit eigenem Ziel, Zugang und Netzwerkweg.
MariaDB und PostgreSQL sind Datenbankdienste. Adminer und pgAdmin sind Werkzeuge, mit denen du diese Dienste bedienst. Diese Trennung ist ein Sicherheits- und Wartungsvorteil: Eine neu gestartete oder aktualisierte Oberfläche darf die Datenbank selbst nicht stoppen.
Warum dieser Test wichtig ist: Eine geladene Anmeldeseite beweist nur, dass der Webdienst antwortet. Erst die erfolgreiche Anmeldung und die sichtbare Datenbank projekt_test zeigen, dass Adminer auch den MariaDB-Dienst im internen Netzwerk erreicht.
Adminer und pgAdmin bekommen im Buch einen klaren Platz im Aufbau. Du verfolgst den Weg von der erreichbaren Oberfläche zur erfolgreichen Datenbankverbindung und lernst, welche Kontrolle welchen Teil dieses Weges belegt. Für Verwaltungszugänge ist dabei der Zugriff über Heimnetz oder VPN vorgesehen.
Wenn später eine Anmeldung scheitert, hilft diese Trennung: Du kannst gezielt nachsehen, ob die Oberfläche antwortet, der Datenbankdienst erreichbar ist oder die Zugangsdaten passen. Aus „geht nicht“ werden Fragen, die Du einzeln prüfen kannst.
Lust auf den nächsten Schritt?
Verstehen, warum es läuft. Und erkennen, wenn etwas fehlt.
Die Leseprobe zeigt die Fragen. Die vollständigen Kapitel verbinden sie mit dem Aufbau, den Prüfungen und den Erfahrungen aus dem Projekt: vom Plan für die Infrastruktur über die ersten Monitore bis zu Datenbanken und ihrer Verwaltung.
Wenn Du schon einmal vor einer grünen Statusanzeige saßt und trotzdem nicht weiterwusstest, findest Du hier vertraute Situationen. Und vielleicht genau die nächste Frage, die Deinem eigenen Heimserver noch gefehlt hat.
Wie alles begonnen hat
Band 1 führt von der Projektidee über Docker und Compose bis zur eigenen Webseite. Oder entdecke, welche weiteren Themen in der Buchreihe entstehen.