Limits & Kontingente

Rediacc-Deployment-Limits. Drei davon sind hart und können nicht durch Hardware-Ergänzungen geändert werden: die Obergrenze von 61 Diensten pro Repository (Netzwerkadressraum-Zuteilung), die Kernel-6.1-Mindestversion (CRIU-Anforderungen) und das Let’s Encrypt-Ausstellungs-Limit von 50 Wildcard-Zertifikaten pro registrierter Domain pro Woche. Alles andere ist weich: es ändert sich mit zusätzlicher Hardware. Kennen Sie den Unterschied, bevor Sie sich auf eine Topologie festlegen.

---

Dienste pro Repository

Jedes Repository unterstützt bis zu 61 Dienste, die gleichzeitig ausgeführt werden.

Dies ist ein festes Limit, das durch den Netzwerkadressraum bestimmt wird, der jedem Repository zugewiesen ist. Jeder Dienst erhält seine eigene dedizierte private IP-Adresse, und der Adressblock jedes Repositories bietet Platz für genau 61 Dienst-Slots.

Das Erreichen von 61 Diensten in einem Repository signalisiert normalerweise ein Architektur-Problem, kein Rediacc-Limit. Verschieben Sie Sidecars und Monitoring-Agenten in ihr eigenes Repository mit separater Isolationsgrenze, oder reduzieren Sie die Anzahl der unabhängig laufenden Prozesse in der Anwendung selbst.

---

Repositories pro Maschine

Es gibt kein festes Limit, das von Rediacc erzwungen wird. Das praktische Limit hängt von den Ressourcen Ihrer Maschine ab:

Ressource	Auswirkung
Festplattenspeicher	Jedes Repository ist ein verschlüsseltes Disk-Image. Eine Maschine mit 1 TB nutzbarem Speicher kann viele Repositories aufnehmen, aber die Gesamtgröße aller Images muss in den Datastore-Pool passen.
RAM	Jedes laufende Repository startet seinen eigenen Docker-Daemon und Container. Der Speicherverbrauch hängt von Ihren Workloads ab.
CPU	Parallele Repository-Operationen (Start, Backup, Fork) erzeugen vorübergehende CPU-Last.

Typische Deployments führen 10 bis 50 Repositories pro Maschine problemlos aus. Maschinen mit 32 GB+ RAM und 500 GB+ Speicher betreiben regelmäßig mehr als 100 Repositories.

Systemweites Netzwerk-ID-Limit

Jedem Repository wird eine eindeutige Netzwerk-ID zugewiesen, eine Zahl, die zur Berechnung seines privaten IP-Adressbereichs verwendet wird. Dieser Pool wird von allen Maschinen und Repositories geteilt, die von derselben Rediacc-Konfiguration verwaltet werden.

Limit	Wert
Verfügbare Netzwerk-IDs insgesamt	~261.944
Geltungsbereich	Pro Konfiguration (geteilt über alle Maschinen in einer Konfiguration)

Wenn ein Repository gelöscht wird, wird seine Netzwerk-ID freigegeben und steht zur Wiederverwendung bereit. Rediacc weist IDs sequenziell zu und sucht erst nach freigegebenen Lücken, wenn der Vorwärtszähler sich der Obergrenze nähert. In der Praxis wird dieses Limit nie erreicht. Es würde erfordern, Hunderttausende von Repositories über die Lebensdauer einer einzelnen Konfiguration zu erstellen und zu verwalten.

---

Forks

Es gibt kein Limit für die Anzahl aktiver Forks eines Repositories. Jeder Fork ist ein vollständiger Copy-on-Write-Klon mit eigenem verschlüsseltem Speicher, eigenen Netzwerkadressen und eigenem Docker-Daemon. Forks verbrauchen Festplattenspeicher proportional zu den Daten, die nach der Erstellung geschrieben werden (nicht die volle Größe des Eltern-Repositories).

---

Externe Ports

Immer aktive Ports

Ports werden erst geöffnet, wenn Sie eine öffentliche IP mit rdc machine infra set <machine> --public-ipv4 konfigurieren. Bis dahin sind keine Ports auf der Maschine geöffnet. Nach der Konfiguration:

Port	Protokoll	Zweck
80	TCP	HTTP: wird von Traefik verarbeitet; gibt 404 für nicht konfigurierte Domains zurück, wird an keinen Dienst weitergeleitet
443	TCP	HTTPS: wie oben; Anfragen ohne passende Route werden auf der Proxy-Ebene abgelehnt
10000-10010	TCP	Dynamischer Bereich für Rediacc-verwaltete TCP-Weiterleitung

HTTP/HTTPS unterscheiden sich von rohen TCP-Ports: Obwohl 80 und 443 geöffnet sind, wird jede Anfrage vom Reverse Proxy gegen eine explizite Routing-Tabelle validiert. Ohne einen konfigurierten Dienst und eine passende Domain wird kein Anwendungscode erreicht und keine Daten werden offengelegt.

Optionale TCP/UDP-Weiterleitung

Alle anderen Ports (Datenbanken, Caches, Message Broker, DNS, Mail) sind standardmäßig geschlossen und müssen explizit geöffnet werden. Dies hält die Angriffsfläche der Maschine minimal.

Um einen Port eines bestimmten Dienstes freizugeben:

labels:
  - "rediacc.tcp_ports=5432"   # expose PostgreSQL from this container
  - "rediacc.udp_ports=53"     # expose DNS from this container

Um einen Port auf Maschinenebene zu öffnen (verfügbar für alle Dienste):

rdc machine infra set server-1 --tcp-ports 25,587,993   # mail server
rdc machine infra push server-1

Geben Sie niemals Datenbank- oder Cache-Ports extern frei, es sei denn, Sie haben eine spezifische Anforderung. Verwenden Sie HTTPS-Auto-Routen für Webdienste und halten Sie Speicherdienste intern.

---

Datastore

Der Datastore ist ein Pool fester Größe, der bei der Ersteinrichtung einer Maschine erstellt wird. Seine Größe wächst nicht automatisch.

• Empfohlene Mindestgröße: 50 GB
• Maximale Größe: Begrenzt durch Ihre Festplatte. Ein einzelner Pool kann eine gesamte Festplatte umfassen.
• Größenanpassung: Verwenden Sie rdc datastore resize, um die Pool-Größe zu ändern (alle Repositories müssen vorher unmountet sein).
• Dateisystem: Rediacc verwendet intern BTRFS für Copy-on-Write-Snapshots und effizientes Forking. Erfordert eine Maschine mit Linux Kernel 6.1 oder neuer für volle Produktionsstabilität.

Jedes Repository hat eine maximale Größe, die bei der Erstellung festgelegt wird (Standard: 10 GB). Verwenden Sie rdc repo resize, um sie manuell zu ändern, oder richten Sie eine automatische Größenrichtlinie ein, damit die Maschine das Repository im laufenden Betrieb vergrößert, wenn es sich füllt (begrenzt durch eine explizite Repository-Obergrenze und eine Pool-Freispeicherreserve). Auto-Grow gilt nur für einzelne Repositories; der Pool selbst wird nie automatisch vergrößert.

Repository-Images sind sparse: Ein Repository belegt im Pool nur den Speicher, den es tatsächlich geschrieben hat, und durch Löschungen freigegebener Speicher wird über repo trim oder ein geplantes Auto-Trim an den Pool zurückgegeben. Quotas können daher in der Summe die Pool-Größe übersteigen, wobei der Speichergesundheitsbericht den tatsächlichen Füllstand anzeigt.

---

HTTP-Routen

Jeder Dienst mit dem Label rediacc.service_port erhält automatisch eine HTTPS-Route. Es gibt kein Limit für die Anzahl der Dienste mit Routen, vorbehaltlich des Maximums von 61 Diensten pro Repository.

Wildcard-TLS-Zertifikate werden pro Repository beim ersten Deployment über Let’s Encrypt (Cloudflare DNS-01 Challenge) bereitgestellt. Let’s Encrypt begrenzt die Ausstellung auf 50 Zertifikate pro registrierter Domain pro Woche. Da Rediacc ein Wildcard-Zertifikat pro Repository verwendet (nicht pro Dienst), wird ein Deployment, das in einer einzigen Woche mehr als 50 neue Repositories erstellt, diese Grenze erreichen.

Forks verwenden das vorhandene Wildcard-Zertifikat des Eltern-Repositories wieder und verbrauchen kein Zertifikatskontingent.

---

Checkpoint / Restore (CRIU)

Live-Migration über CRIU hat folgende Einschränkungen:

• Opt-in: Nur Container mit dem Label rediacc.checkpoint=true werden gesichert. Datenbanken und zustandslose Dienste sind standardmäßig ausgeschlossen und starten bei der Wiederherstellung neu.
• Kernel-Anforderung: Linux 6.1+ auf sowohl der Quell- als auch der Zielmaschine.
• Netzwerkmodus: CRIU erfordert den Host-Netzwerkmodus. Container mit benutzerdefinierten Netzwerkkonfigurationen können nicht gesichert werden.
• Arbeitsspeicher: Die Größe der Checkpoint-Daten entspricht dem residenten Speicher des gesicherten Prozesses. Große In-Memory-Datensätze (z. B. eine Node.js-App, die 4 GB Daten zwischenspeichert) erzeugen 4 GB Checkpoint-Dateien.
• TCP-Verbindungen: Anwendungen müssen Verbindungsverluste bei der Wiederherstellung tolerieren. Aktive TCP-Verbindungen bleiben nicht erhalten. Der wiederhergestellte Prozess sieht Sockets als geschlossen und muss die Verbindung neu aufbauen. Dies gilt sowohl für Wiederherstellungen auf derselben Maschine als auch für maschinenübergreifende Wiederherstellungen.
• Live-Fork auf derselben Maschine leitet Eltern-Adressen um: rdc repo fork X --tag Y --checkpoint gefolgt von rdc repo up funktioniert, während das Eltern-Repository weiterläuft. Die wiederhergestellten Prozesse tragen die Loopback-Adressen des Eltern-Repositories vom Zeitpunkt des Checkpoints, daher leitet das System sie transparent auf die eigenen Adressen des Forks um (gleicher Dienst, Fork-Kopie der Daten). Die erste Nutzung einer wiederhergestellten TCP-Verbindung schlägt weiterhin fehl und die App muss sich neu verbinden, siehe den TCP-Punkt oben.

---

Backups

Limit	Wert
Snapshots pro Repository	Keine Begrenzung über Ihr Speicherkontingent hinaus. Jeder Snapshot ist unabhängig wiederherstellbar, daher kostet das Aufbewahren weiterer Snapshots nur Speicherplatz und sonst nichts
Gleichzeitige Snapshots eines Repositorys	1. Ein zweiter Lauf findet die Staging-Sperre des Repositorys belegt vor und wird übersprungen, nicht in die Warteschlange gestellt: Er meldet, dass ein anderer Lauf sie hält, und beendet sich. Führen Sie ihn danach erneut aus
Gleichzeitige Cold-Snapshots	1 pro Datastore; ein zweiter renet backup snapshot --cold wird sofort zurückgewiesen und stoppt nichts
Backup-Häufigkeit	Kein Mindestintervall erzwungen; begrenzt durch Ihre Speicherbandbreite. Verwenden Sie rdc backup strategy set <name> --bwlimit "6M", um die Upload-Geschwindigkeit zu begrenzen
Aufbewahrung	Wird mit rdc backup retention set deklariert (--keep-last, --keep-hourly, --keep-daily, --keep-weekly, --keep-monthly, --keep-yearly) und auf der Serverseite erzwungen; rdc backup retention clear entfernt sie, danach wird jeder Snapshot behalten
Maschinenübergreifendes Backup	Unterstützt; die Zielmaschine muss über ausreichend Datastore-Speicherplatz verfügen

Backup-Speicherkontingent

Snapshots gehen an den Chunk-Storage, der pro Abonnement in physischen eindeutig gespeicherten Bytes gemessen wird: was nach Deduplizierung tatsächlich gehalten wird, nicht die Summe dessen, was Ihre Snapshots logisch darstellen. Snapshots, die Daten teilen, und Repositories derselben Fork-Familie zählen diese Daten nur einmal.

Plan	Kontingent	Angezeigt von rdc backup usage als
Community	10 GB	10G
Professional	100 GB	100G
Business	500 GB	500G
Enterprise	2 TB	2T

Dies sind die Standardwerte des Plans. Ein Abonnement kann eine eigene Überschreibung tragen, prüfen Sie daher rdc backup usage, statt die obige Zeile anzunehmen.

Das Kontingent wird durchgesetzt, bevor sich Daten bewegen: Ein Snapshot, der es überschreiten würde, wird zurückgewiesen, wenn die Maschine um die Erlaubnis zum Hochladen bittet, nicht mitten in der Übertragung. Genau auf dem Kontingent zu landen ist erlaubt; ein Byte darüber wird zurückgewiesen. Was als genutzt zählt, umfasst noch laufende Uploads, sodass sich zwei gleichzeitige Läufe nicht beide unter die Grenze quetschen können.

Eine Kontingentüberschreitung löscht niemals etwas. Sie stoppt nur neue Uploads, und die bereits vorhandenen Snapshots bleiben, wo sie sind.

Läuft ein Abonnement aus, wird der Backup-Speicher schreibgeschützt: Vorhandene Snapshots bleiben lesbar, und es können keine neuen hochgeladen werden. Diese Daten werden 60 Tage nach dem Ablauf aufbewahrt, danach entfernt sie ein einziger Durchlauf. Eine offene Rückerstattung für die Organisation friert diesen Durchlauf ein, statt ihn auszuführen.

Maschine-zu-Maschine-Kopien mit rdc repo push berühren dieses Kontingent nicht. Sie landen im Datastore der Zielmaschine und sind durch dessen freien Speicherplatz begrenzt.

---

CLI & API

Limit	Wert
Gleichzeitige rdc-Befehle gegen dieselbe Maschine	Unbegrenzt (jeder Befehl öffnet seine eigene SSH-Verbindung)
Standard-Parallelität beim Repository-Start	3 (anpassbar mit --concurrency)
SSH-Verbindungs-Timeout	30 Sekunden für die initiale Verbindung
rdc-Sitzungsdauer	Kein Timeout; lang laufende Operationen halten die Verbindung aufrecht

---

Unterstützte Betriebssystemversionen

Remote-Maschinen müssen eines der folgenden Systeme ausführen, um die Kernel-, Dateisystem- und Netzwerkisolationsanforderungen von Rediacc zu erfüllen. Diese Liste ist der maßgebliche CI-getestete Satz (Bridge Workers-Matrix) und muss synchron mit Anforderungen bleiben:

Betriebssystem	Mindestversion	Standard-Kernel	Hinweise
Ubuntu	24.04 LTS (empfohlen)	6.8	AppArmor Standard.
Debian	13 (Trixie); 12 Bookworm funktioniert ebenfalls	6.12 (6.1 auf Debian 12)
Fedora	43	6.12	SELinux enforcing Standard.
openSUSE Leap	16.0	6.4+	AppArmor Standard.
Oracle Linux	10 (UEK)	UEK 7+	UEK behält btrfs; SELinux enforcing Standard.

Erforderlicher Mindest-Kernel: 6.1. Maschinen mit älteren Kernels werden bei der Einrichtung mit einer klaren Fehlermeldung abgelehnt.

Warum Kernel 6.1? Rediacc verwendet BTRFS für verschlüsselten Repository-Speicher und Copy-on-Write-Forking. Linux 6.1 führte kritische BTRFS-Verbesserungen ein, die die Mount-Zeiten für große Datastores erheblich reduzieren, die Leistung beim Löschen von Snapshots verbessern und Datenintegritätsprobleme früherer Kernel beheben. Kernel 6.1 wird auch für die Netzwerkisolations-Hooks auf Kernel-Ebene benötigt, die die Repository-übergreifende Isolation erzwingen, indem sie bind()-Aufrufe transparent umschreiben und Verbindungen zwischen Repositories blockieren.

Warum nicht Rocky Linux 10 / RHEL 10 Stock-Kernel? Der Stock-Kernel von RHEL 10 wird ohne das btrfs-Modul ausgeliefert (modprobe btrfs schlägt mit “Module btrfs not found” fehl). Rediacc’s verschlüsseltes Storage-Backend kann ohne btrfs nicht laufen. Oracle Linux 10 ist das einzige RHEL-kompatible Ziel auf der unterstützten Liste, weil es standardmäßig den Unbreakable Enterprise Kernel (UEK) verwendet, der btrfs beibehält. Siehe Anforderungen: Warum UEK? für die vollständige Erläuterung.

Kernel-Feature-Matrix

Die Matrix zeigt auf einen Blick, was jedes CI-getestete Betriebssystem out-of-the-box bereitstellt. Alle fünf erfüllen jede Anforderung, daher ist dies eine operatorbezogene Referenz, kein Auswahlkriterium.

Betriebssystem	btrfs-Modul	cgroups v2	Landlock (ABI >= 1)	eBPF cgroup Hooks
Ubuntu 24.04	im Kernel	unified hierarchy	ja (5.13+)	ja
Debian 13	im Kernel	unified hierarchy	ja	ja
Fedora 43	im Kernel	unified hierarchy	ja	ja
openSUSE Leap 16.0	im Kernel	unified hierarchy	ja	ja
Oracle Linux 10 (UEK)	im Kernel (via UEK)	unified hierarchy	ja	ja