Ein Git-Server auf dem NAS betrifft vor allem den Dienst, seine Benutzerrechte und den Speicherort der Repositories – nicht das RAID selbst. Eine akute Datengefahr besteht bei einer neuen Einrichtung normalerweise nicht, solange du keine bestehende Freigabe umwidmest oder Verzeichnisse verschiebst. Prüfe zuerst, ob dein NAS Container oder einen gepflegten Git-Dienst unterstützt und ob ein externes Backup vorhanden ist. Initialisiere, formatiere oder verändere den Speicherpool für diese Aufgabe nicht.
Für mehrere Benutzer und eine komfortable Verwaltung ist eine Plattform wie Gitea oder Forgejo meist sinnvoller als eine lose Sammlung von Git-Verzeichnissen. Ein schlanker Git-Zugang über SSH kann dagegen genügen, wenn nur wenige vertraute Personen arbeiten und keine Weboberfläche, Issues oder Zugriffseinstellungen je Repository benötigt werden. In beiden Fällen sollte der Server ausschließlich im vertrauenswürdigen Heimnetz oder über ein VPN erreichbar sein.
Die passende Betriebsform für deine Repositories
Die technische Entscheidung fällt zwischen einem reinen Git-Dienst und einer vollständigen Git-Plattform. Beide Varianten speichern die Versionsgeschichte zentral, unterscheiden sich aber deutlich bei Verwaltung, Wartung und Sicherung.
- Bare Repositories über SSH: Diese Variante benötigt wenig Leistung und wenige Komponenten. Benutzerkonten, SSH-Schlüssel und Dateirechte müssen jedoch sorgfältig verwaltet werden. Eine grafische Repository-Verwaltung, Pull Requests und Issues fehlen.
- Gitea oder Forgejo: Eine Weboberfläche verwaltet Benutzer, Organisationen, Teams und einzelne Projekte. Dafür müssen neben den Repositories auch Anwendungskonfiguration, Datenbank, Schlüssel und gegebenenfalls Anhänge gesichert werden.
- Git-Paket des NAS-Herstellers: Ein solches Paket kann die Einrichtung vereinfachen, sofern es für das Modell und die installierte Betriebssystemversion angeboten und weiterhin gepflegt wird. Funktionsumfang und Aktualisierungsrhythmus hängen vom Hersteller ab.
Ein Bare Repository ist eine zentrale Git-Ablage ohne ausgecheckte Arbeitskopie. Entwickler bearbeiten den Code weiterhin auf ihren Rechnern und übertragen Commits mit Push zum NAS. Quellcode direkt in einer normalen SMB-Freigabe gemeinsam zu bearbeiten, ist kein Ersatz für einen Git-Server: Gleichzeitige Änderungen, Dateisperren und unterschiedliche Clientzustände können die Arbeitskopie beschädigen oder unübersichtlich machen.
Gitea und Forgejo passen besser, sobald mehrere Projekte oder Personen getrennte Rechte benötigen. Prüfe vor der Installation in der Paket- oder Containerverwaltung deines NAS, welche Architektur, Betriebssystemversion und Container-Engine unterstützt werden. Herstelleroberflächen und Bezeichnungen ändern sich; maßgeblich sind die Funktionsseiten für Container beziehungsweise Anwendungen sowie die Dokumentation der eingesetzten Git-Plattform.
Speicher, Dienst und Benutzer sauber trennen
Lege Git-Daten nicht wahllos in einer allgemeinen Benutzerfreigabe ab. Sinnvoll ist ein eigener gemeinsamer Ordner oder ein eigenes Dataset innerhalb eines vorhandenen, gesunden Volumes. Dieser Speicherort erhält nur die Rechte, die der Git-Dienst tatsächlich benötigt.
Bei einer containerisierten Plattform sind mindestens zwei Datenarten zu unterscheiden:
- dauerhafte Anwendungsdaten mit Repositories, Konfiguration und internen Schlüsseln,
- die Datenbank, die Benutzer, Rechte, Projekteinstellungen, Issues und weitere Metadaten enthält.
Verwendest du eine externe Datenbank, gehört sie ausdrücklich in das Sicherungs- und Wiederherstellungskonzept. Liegt die Datenbank innerhalb des persistenten Anwendungsverzeichnisses, musst du trotzdem die von der Plattform vorgesehene konsistente Sicherungsmethode beachten. Das bloße Kopieren aktiver Datenbankdateien kann zu einer unbrauchbaren Sicherung führen.
Der Container oder Dienst sollte unter einem eigenen, nicht administrativen Konto laufen. Dieses Konto benötigt Schreibzugriff auf seine persistenten Verzeichnisse, aber keinen Zugriff auf private Dokumente, Medienarchive oder NAS-Systembereiche. Persönliche NAS-Administratorkonten sind dafür ungeeignet.
Vom leeren Dienst bis zum ersten erfolgreichen Abruf
- Systemzustand prüfen: Kontrolliere Speicherpool, Volume und verfügbare Kapazität. Sichere die bestehende NAS-Konfiguration und vergewissere dich, dass ein unabhängiges Backup wichtiger Daten vorhanden ist.
- Betriebsform festlegen: Wähle einen gepflegten Herstellerdienst, eine unterstützte Containerplattform oder einen reinen SSH-Zugang. Bei Containern müssen Image-Architektur und NAS-Prozessor zusammenpassen.
- Eigenen Speicherort anlegen: Erstelle einen Ordner oder ein Dataset nur für den Git-Dienst. Weise dem Dienstkonto die erforderlichen Rechte zu und entferne pauschale Schreibrechte für normale NAS-Benutzer.
- Persistenz zuordnen: Verbinde bei Gitea oder Forgejo das dauerhafte Anwendungsverzeichnis mit dem vorgesehenen Datenpfad des Containers. Eine rein interne, nicht zugeordnete Container-Schicht würde beim Löschen oder Neuerstellen des Containers verloren gehen.
- Netzwerkzugriff begrenzen: Veröffentliche Web- und SSH-Zugang nur im Heimnetz. Prüfe, ob ein gewählter SSH-Port mit dem Verwaltungszugang des NAS kollidiert. Eine Portkollision muss durch eine andere Zuordnung oder eine getrennte Adresse gelöst werden, nicht durch das Abschalten eines benötigten Verwaltungsdienstes.
- Erstes Administratorkonto absichern: Verwende ein eigenes starkes Kennwort und aktiviere Mehrfaktor-Authentifizierung, sofern die eingesetzte Plattform sie unterstützt. Deaktiviere eine offene Selbstregistrierung, wenn nur bekannte Haushalts- oder Teammitglieder Zugriff erhalten sollen.
- Benutzer und Schlüssel einrichten: Jeder Benutzer erhält ein eigenes Konto und einen eigenen SSH-Schlüssel. Gemeinsame Schlüssel erschweren es, Zugriffe zuzuordnen und einzelne Geräte später gezielt zu sperren.
- Testprojekt erstellen: Lege zunächst ein unwichtiges privates Repository an. Die Plattform zeigt dessen HTTPS- oder SSH-Adresse an; diese Adresse trägst du im Git-Client als Remote ein.
- Schreib- und Lesetest ausführen: Übertrage eine kleine Testdatei, rufe das Repository auf einem zweiten lokalen Verzeichnis oder einem anderen Rechner erneut ab und vergleiche den Commitstand. Erst nach erfolgreichem Push und erneutem Abruf sollten produktive Projekte folgen.
Bei einem reinen SSH-Dienst ist die Erfolgskontrolle ähnlich: Der Client muss sich mit seinem persönlichen Schlüssel anmelden, das Bare Repository erreichen und einen Commit übertragen sowie wieder abrufen können. Eine interaktive Shell ist für ein reines Git-Konto in der Regel nicht erforderlich. Ob sie eingeschränkt werden kann, hängt von der verwendeten Serverlösung ab.
Zugriff im Heimnetz ohne unnötige Angriffsfläche
Ein privates Repository ist nur so geschützt wie sein schwächstes Konto und das Gerät, auf dem ein Zugangsschlüssel liegt. Verwende pro Person und möglichst pro Gerät getrennte SSH-Schlüssel. Geht ein Notebook verloren, kannst du dessen Schlüssel sperren, ohne alle anderen Clients neu einzurichten.
Für HTTPS benötigt die Weboberfläche ein vertrauenswürdiges Zertifikat, damit Zugangsdaten und Sitzungen nicht unverschlüsselt übertragen werden. Im reinen Heimnetz kann dies über einen internen Reverse Proxy und eine lokal vertrauenswürdige Zertifikatslösung erfolgen. Browserwarnungen dauerhaft zu ignorieren, ist keine saubere Lösung, weil Benutzer dann echte Zertifikatsprobleme kaum noch erkennen.
Direkte Routerfreigaben für Weboberfläche oder SSH sind keine sinnvolle Standardeinstellung. Soll ein Entwickler von unterwegs zugreifen, führt der sichere Weg zunächst über ein VPN ins Heimnetz. Die Git-Plattform bleibt dabei intern erreichbar, während das VPN Authentifizierung und Netzgrenze übernimmt. Zusätzlich sollten das NAS und die Anwendung fehlgeschlagene Anmeldungen protokollieren und wiederholte Versuche begrenzen können.
Rechte je Projekt statt pauschaler NAS-Zugriff
Die Dateirechte des NAS schützen den Speicherbereich des Dienstes. Die Rechte innerhalb von Gitea oder Forgejo steuern dagegen, wer ein Repository sehen, beschreiben oder verwalten darf. Diese Ebenen dürfen nicht verwechselt werden.
Normale Entwickler benötigen gewöhnlich keine direkten SMB-Rechte auf den Repository-Ordner. Sie greifen über Git auf den Dienst zu. Direkter Dateizugriff am Dienst vorbei kann Berechtigungen verändern, Sperrdateien hinterlassen oder Daten während eines Schreibvorgangs inkonsistent kopieren. Administration und Projektberechtigungen sollten ebenfalls getrennt bleiben: Wer Code übertragen darf, muss nicht automatisch Benutzer, Schlüssel oder Systemeinstellungen verwalten können.
Backup muss mehr als den Repository-Ordner erfassen
RAID hält einen Dienst bei einem einzelnen Laufwerksausfall möglicherweise verfügbar, ersetzt aber keine Sicherung. Es schützt weder vor gelöschten Repositories noch vor Fehlkonfiguration, Schadsoftware, Dateisystemproblemen oder dem Verlust des gesamten NAS.
Eine belastbare Sicherungsfolge sieht so aus:
- Die Plattform mit ihrer vorgesehenen Backup- oder Exportfunktion in einen konsistenten Zustand bringen.
- Den erzeugten Sicherungsbestand versioniert auf ein getrenntes Ziel kopieren.
- Mindestens eine weitere Kopie außerhalb des NAS aufbewahren und sensible Repositories vor dem Transport verschlüsseln.
- In einer isolierten Testumgebung regelmäßig eine Wiederherstellung durchführen.
Snapshots auf demselben Volume ermöglichen einen schnellen Rücksprung nach versehentlichem Löschen, bleiben aber vom Zustand des NAS und seines Speicherpools abhängig. Sie ergänzen ein externes Backup, ersetzen es nicht. Auch Arbeitskopien auf Entwicklerrechnern sind keine vollständige Serversicherung: Nicht jeder Clone enthält alle administrativen Metadaten, LFS-Inhalte oder sämtliche noch nicht abgerufenen Zweige anderer Benutzer.
Updates ohne Verlust von Projektdaten
Vor einem Update sicherst du die persistenten Daten und prüfst die Wiederherstellbarkeit. Bei einem Container wird anschließend nur das Image ersetzt; die dauerhaften Verzeichnisse bleiben eingebunden. Lösche einen alten Container erst, wenn seine Pfadzuordnungen, Umgebungswerte und Netzwerkeinstellungen dokumentiert sind und der neue Dienst erfolgreich startet.
Nach dem Update reicht eine erreichbare Anmeldeseite nicht als Kontrolle. Melde dich mit einem normalen Benutzerkonto an, öffne ein privates Testprojekt, führe einen Abruf und einen Push aus und kontrolliere die Protokolle auf Datenbank-, Rechte- oder Speicherfehler. Prüfe außerdem, ob SSH-Schlüssel, Zwei-Faktor-Anmeldung und Projektberechtigungen erhalten geblieben sind.
Schlägt ein Update fehl, vermeide übereilte Neuinstallationen. Sichere zunächst Protokolle, Versionsangaben, Containerparameter und den unveränderten Datenbestand. Ein Rollback ist nur sicher, wenn die ältere Anwendung das bereits migrierte Datenbankschema unterstützt oder eine passende Sicherung vor der Migration zurückgespielt wird.
Kapazität und Grenzen eines NAS als Git-Zentrale
Normale Quelltext-Repositories benötigen meist wenig Rechenleistung. Spürbare Anforderungen entstehen eher durch viele gleichzeitige Benutzer, große Binärdateien, serverseitige Suchindizes, Paketregistries oder automatisierte Builds. Git Large File Storage kann große Dateien aus der eigentlichen Git-Historie auslagern, erhöht aber den Speicher- und Backupbedarf des Servers.
CI-Aufgaben solltest du von der reinen Repository-Speicherung unterscheiden. Builds können Prozessor, Arbeitsspeicher und Datenträger stark belasten und dadurch Backups oder andere NAS-Dienste ausbremsen. Falls die Plattform Runner unterstützt, können diese auf einem getrennten Rechner arbeiten. Der Git-Server bleibt dann die zentrale Projektablage, ohne jeden Build selbst auszuführen.
Vor dem produktiven Einsatz sollte der Test nicht nur die Anmeldung bestätigen. Ein belastbarer Stand ist erreicht, wenn ein nicht administrativer Benutzer ein privates Testprojekt über den vorgesehenen Zugangsweg klonen, ändern und übertragen kann, ein unberechtigtes Konto abgewiesen wird und sich das Projekt aus der externen Sicherung wiederherstellen lässt.
Häufige Fragen zum privaten Git-Dienst
Kann ein Repository verschlüsselt auf dem NAS liegen?
Eine verschlüsselte Freigabe oder ein verschlüsseltes Volume kann Daten im ausgeschalteten beziehungsweise gesperrten Zustand schützen. Während der Git-Dienst läuft und der Speicher eingebunden ist, kann das Dienstkonto auf die Daten zugreifen. Prüfe vor Änderungen an der NAS-Verschlüsselung, wo der Wiederherstellungsschlüssel liegt und ob der Dienst nach einem Neustart ohne unsichere Umgehung wieder verfügbar werden soll.
Was geschieht, wenn die NAS-Adresse geändert wird?
Clients erreichen den Server zuverlässiger über einen stabilen lokalen DNS-Namen als über eine wechselnde IP-Adresse. Ändert sich der Name oder der verwendete Port, müssen die hinterlegten Remote-Adressen angepasst werden. Bei SSH kann zusätzlich eine neue Prüfung des Serverschlüssels nötig sein; ein unerwartet geänderter Schlüssel sollte nicht ungeprüft akzeptiert werden.
Eignet sich der Git-Server für große Mediendateien?
Git ist für versionierbaren Quelltext und ähnliche Dateien ausgelegt. Häufig veränderte Videos, Archive oder große Projektdateien lassen die Historie schnell wachsen. Für ausgewählte große Dateien kommt Git LFS infrage, sofern Server und Clients es unterstützen. Umfangreiche Medienbestände gehören meist in eine normale Dateifreigabe oder ein dafür vorgesehenes Versionssystem, während das Repository Quelltext und kleine Projektdateien enthält.