DDI/docs/SYSTEM-REQUIREMENTS.md

Systemvoraussetzungen

Dieses Dokument nennt Betriebssysteme, Software-Versionen, Browser, Größen je Rolle, Netzwerkports und Plattenbedarf der DDI-Suite. Die Richtwerte stützen sich auf Messungen (Abschnitt 4); was geschätzt ist, steht ausdrücklich dabei. Der Installer prüft die Mindestwerte aus Abschnitt 3 vor der Installation. Installation: INSTALL.md, Betrieb: OPERATIONS.md, Sicherheit: SECURITY.md.

1. Betriebssysteme und Architekturen

System	Versionen	Architekturen
Debian	12 (bookworm), 13 (trixie)	amd64, arm64
Ubuntu LTS	22.04, 24.04	amd64, arm64
RHEL-Familie (Rocky Linux, AlmaLinux, RHEL)	9	x86_64, aarch64

Erkennung über /etc/os-release und uname -m. Andere Systeme lehnt der Installer ab. Die Binaries sind statisch gebaut (CGO_ENABLED=0) und laufen auch auf anderen Linux-Systemen, dort aber ohne Installer und ohne Unterstützung. Erforderlich ist systemd (die Units nutzen Härtungsoptionen ab systemd 249).

Alle drei Rollen (server, agent-dns, agent-dhcp) dürfen auf einem Host liegen; die Mindestwerte addieren sich dann (Abschnitt 3).

2. Software

Komponente	Unterstützt	In der CI getestet	Quelle bei der Installation
PostgreSQL (nur Server)	≥ 13	17.11	Paket der Distribution (Debian 12: 15, Debian 13: 17, Ubuntu 22.04: 14, Ubuntu 24.04: 16, EL9: Modul-Stream ≥ 15)
BIND 9 (DNS-Agent)	≥ 9.18	9.18, 9.20	Paket der Distribution (bind9; EL9: bind9.18)
Kea DHCPv4 mit HA (DHCP-Agent)	3.x	3.2.1	ISC-Repository isc/kea-3-2 (Standard, --kea-source isc)
Kea DHCPv4 ohne HA	2.6	2.6.5	Paket der Distribution mit --kea-source distro
systemd	≥ 249	–	Distribution

• Kea-HA braucht Kea ≥ 3.0: Der HA-Partner wird über einen authentifizierten HTTP-Control-Socket angesprochen, Zugangsdaten nur aus Dateien (ADR 0023). Die Distributionen liefern Kea 2.0–2.6; deshalb installiert der Installer standardmäßig aus dem ISC-Repository. Kea-Versionen vor 2.6 sind nicht getestet.
• Genutzt werden nur frei verfügbare Kea-Hooks: libdhcp_lease_cmds.so und libdhcp_ha.so.
• Agents brauchen keine Datenbank; ihr Zustand liegt in Dateien.

Browser

Die Weboberfläche nutzt aktuelles JavaScript (ES2023). Unterstützt sind die jeweils aktuellen Versionen (letzte zwei Hauptversionen) von Firefox, Chrome, Edge und Safari, auf Desktop und Tablet. Ältere Browser und Internet Explorer werden nicht unterstützt. Cookies müssen erlaubt sein (Sitzungscookie); JavaScript ist Pflicht.

3. Richtwerte je Rolle

Größenklassen wie im Auftrag: klein bis ca. 5.000 Adressen und 10 Agents, mittel bis ca. 50.000 Adressen und 50 Agents. „Gemessen“ bedeutet: aus den Messungen in Abschnitt 4 abgeleitet, mit Reserve für Betriebssystem, Spitzen und Wachstum. Die Reserve ist bewusst groß, weil die Messung nur Datenmengen, keine parallelen Benutzer und keine 50 verbundenen Agents abbildet.

Rolle	Klein	Mittel	Grundlage
Management-Server inkl. PostgreSQL	2 vCPU, 2 GB RAM (4 GB empfohlen), 20 GB SSD	4 vCPU, 4 GB RAM (8 GB empfohlen), 50 GB SSD	gemessen: Server 30–195 MiB RSS, Spitze 235 MiB (Anmeldungen mit Argon2id: 64 MiB je gleichzeitiger Anmeldung); PostgreSQL 65–130 MiB; Datenbank 15 bzw. 72 MiB. Platte: Revisionen und Audit-Log wachsen (Abschnitt 7). CPU: Listenabfragen über 50.000 Einträge brauchen 40–240 ms je Anfrage (eine Abfrage = ein Kern), mehrere Benutzer gleichzeitig profitieren von 4 Kernen.
DNS-Agent + BIND	1 vCPU, 512 MB RAM (1 GB empfohlen), 5 GB	2 vCPU, 1 GB RAM (2 GB empfohlen), 10 GB	gemessen: named 22–27 MiB (9.000 Records) bzw. 57–61 MiB (90.000 Records, 657 Zonen); 50.000–70.000 Abfragen/s mit 1,0–1,4 Kernen. Agent geschätzt 20–40 MiB.
DHCP-Agent + Kea	1 vCPU, 512 MB RAM (1 GB empfohlen), 5 GB	2 vCPU, 1 GB RAM (2 GB empfohlen), 10 GB	gemessen: kea-dhcp4 20–35 MiB (1.000 Reservierungen) bzw. 42–58 MiB (10.000 Reservierungen, bis 50.000 Leases); 750–1.000 DORA/s mit rund einem Kern. Agent geschätzt 20–40 MiB.

Gegenüber den Ausgangswerten des Auftrags (Server 4 GB / 8–16 GB, DNS 1 GB / 2–4 GB, DHCP 1 GB / 2 GB) zeigen die Messungen deutlich geringeren Speicherbedarf; die Mindestwerte sind entsprechend gesenkt, die Empfehlungen bleiben nahe am Auftrag, um Reserve für Wachstum, Logs, Paketupdates und Lastspitzen zu lassen. SSD ist für den Server empfohlen (PostgreSQL), für Agents auf einem Raspberry Pi Pflicht (Abschnitt 6).

Vorabprüfung des Installers

Der Installer (scripts/install.sh, ADR 0024) prüft vor der Installation diese Werte. Warnung: Hinweis, Installation läuft weiter (mit --non-interactive ohne Rückfrage). Abbruch: Installation stoppt; mit --force wird daraus eine Warnung (außer bei Betriebssystem und Architektur).

Prüfung	Rolle	Warnung, wenn	Abbruch, wenn
Betriebssystem	alle	–	nicht in Abschnitt 1 (auch mit --force)
Architektur (uname -m)	alle	–	nicht x86_64/amd64 oder aarch64/arm64 (auch mit --force)
CPU-Kerne (nproc)	server	< 2	–
	agent-dns, agent-dhcp	–	–
Arbeitsspeicher (MemTotal)	server	< 3,5 GiB	< 1,8 GiB
	agent-dns	< 900 MiB	< 450 MiB
	agent-dhcp	< 900 MiB	< 450 MiB
Freier Platz im Dateisystem von /var/lib	server	< 20 GiB	< 4 GiB
	agent-dns	< 5 GiB	< 1 GiB
	agent-dhcp	< 5 GiB	< 1 GiB
Freier Platz im Dateisystem von /usr/local/bin bzw. /usr/bin	alle	–	< 200 MiB
Zeitsynchronisation (timedatectl show -p NTPSynchronized, aktiver chronyd/systemd-timesyncd/ntpd)	alle	nicht synchronisiert oder kein Zeitdienst aktiv	–
Port 8443/tcp, 8444/tcp frei (ss -ltn)	server	–	von einem anderen Prozess belegt (bei --upgrade vom eigenen Dienst erlaubt)
Port 53/udp+tcp frei	agent-dns	nur systemd-resolved auf 127.0.0.53	von einem anderen Prozess als named belegt
Port 67/udp frei	agent-dhcp	–	von einem anderen Prozess als kea-dhcp4 belegt (z. B. dnsmasq, isc-dhcp-server)
Port 8001/tcp frei (Kea-HA, Standard ha_port)	agent-dhcp	belegt	–
PostgreSQL-Version des Pakets	server	–	< 13
BIND-Version des Pakets	agent-dns	< 9.18	–
Kea-Version	agent-dhcp	< 3.0 (kein HA möglich)	< 2.6
ISC-Repository erreichbar (443/tcp, nur --kea-source isc)	agent-dhcp	–	nicht erreichbar (Hinweis auf --kea-source distro)
Lizenzserver https://license.beugsiud.de erreichbar	server	nicht erreichbar	–
Agent-Port des Servers erreichbar (--server)	agent-dns, agent-dhcp	nicht erreichbar	–

Mehrere Rollen auf einem Host: Speicher- und Plattengrenzen werden addiert (z. B. server + agent-dns + agent-dhcp: Warnung unter 5,3 GiB RAM bzw. 30 GiB Platte, Abbruch unter 2,7 GiB bzw. 6 GiB), für CPU gilt der höchste Wert. Die Grenzen liegen etwas unter den Nennwerten (4 GB, 2 GB, 1 GB, 512 MB), weil der Kernel einen Teil des Speichers für sich behält und MemTotal deshalb kleiner ist.

4. Messungen

Gemessen mit dem Benchmark in test/bench/ (make bench, Workflow bench in .gitea/workflows/bench.yml) auf dem CI-Runner. Maßgeblich ist Lauf 93 vom 15.10.2026 (Commit f5f6ceb); wo ein früherer Lauf (82 vom 14.10.2026, Commit 9c61d31, gleiche Hardware) deutlich abwich, ist die Spanne beider Läufe angegeben. Der CSV-Import stammt aus Lauf 95 vom 15.10.2026 (Commit 7ea66d9, nach der Beschleunigung des Imports). Alle Dienste liefen gleichzeitig als Container auf einem Docker-Host:

Hardware des Runners
CPU	Intel Xeon (Skylake, IBRS), virtualisiert
Kerne (nproc)	4
RAM	7,7 GiB
Kernel / Docker	5.15.0-130-generic / 29.1.4

Der Docker-Daemon kann mit anderen CI-Jobs geteilt sein, und Lastgenerator und Dienst teilen sich dieselben 4 Kerne; zwischen den beiden Läufen schwankten die Durchsätze von BIND und Kea deshalb um bis zu 30 %. Die Werte sind daher eher untere Grenzen dessen, was auf dedizierter Hardware möglich ist.

Methode

• Daten (test/bench/datagen.sh): je 1.000 Einträge in /21-Netzen 10.x.y.0/21 (70 % static, 20 % manual_dhcp mit MAC, 10 % reserved; DHCP-Pool in der oberen Hälfte jedes Netzes), alle Namen in der Zone bench.test. Datensatz klein: 5 Netze, 5.000 Einträge; mittel: 50 Netze, 50.000 Einträge. Zusätzlich ein DHCP-Netz 10.200.0.0/16 mit einem Pool über fast das ganze /16 für perfdhcp.
• Server (Build wie im Release, PostgreSQL 17.11 mit den Standardwerten des offiziellen Images): Import über POST /api/v1/addresses/import in Dateien zu 5.000 Zeilen, danach Messung von Speicher (VmRSS/VmHWM des Prozesses, docker stats für PostgreSQL), Datenbank- und Tabellengrößen, POST /revisions (Dauer, Tabellenwachstum und gespeicherte, komprimierte Größe), GET /config/preview, GET /config/pending, 20 Wiederholungen je Filter von GET /addresses?limit=100 (Median und 95. Perzentil), 50 Umbenennungen per PUT /addresses/{id} mit Wachstum des Audit-Logs, danach eine weitere Revision.
• BIND 9.20: Die Dateien aus GET /config/preview (unverändert) in einem BIND-Container, named neu gestartet; Ladezeit aus dem BIND-Log („starting BIND“ bis „all zones loaded“). dnsperf (Debian-Paket) in einem eigenen Container: 15 s mit 16 Clients und bis zu 500 offenen Abfragen (A und PTR existierender Namen, 10 % NXDOMAIN), dann 15 s mit festen 5.000 Abfragen/s.
• Kea 3.2.1: kea-dhcp4.conf aus GET /config/preview; einzige Änderung: Das /16-Testnetz erhält die Adresse des perfdhcp-Containers als Relay (relay.ip-addresses), weil Relay-Adressen noch nicht im IPAM-Modell stehen. perfdhcp (ISC-Paket) sendet als Relay per Unicast, je 10 s mit 50.000 simulierten Clients bei steigender Rate; spätere Läufe verlängern teils bestehende Leases. CPU aus /proc/<pid>/stat (100 % = ein Kern).

Ergebnisse: Management-Server

Messgröße	5.000 Einträge	50.000 Einträge
Netze / Adresseinträge	6 / 5.000	51 / 50.000
CSV-Import über die API	4,4 s (1.130 Einträge/s)	41 s für 45.000 neue (1.090 Einträge/s)
Server-RSS nach dem Import / Höchstwert	29 / 235 MiB	33 / 235 MiB
Server-RSS am Ende (nach Vorschau, Revisionen)	37–53 MiB	137–194 MiB
PostgreSQL-Container (Speicher)	67 MiB	128 MiB
Datenbankgröße nach dem Import	15 MiB	72 MiB
davon Tabelle addresses inkl. Indizes	2,1 MiB	20 MiB
davon Audit-Log (ein Eintrag je importierter Adresse)	4,3 MiB (5.010 Einträge)	42 MiB (50.107 Einträge)
POST /revisions	0,29–0,34 s	2,8–2,9 s
Speicher je Revision: Tabellenwachstum / gespeicherte Daten	0,7 / 0,5 MiB	4,6 / 4,2 MiB
Erzeugte Dateien: DNS-Dateien / Gesamtgröße	300 / 0,8 MiB	660 / 7,0 MiB
GET /config/preview	0,09 s	0,62 s
GET /config/pending	0,08 s	0,71–0,89 s
GET /addresses?limit=100 ohne Filter (Median / p95)	13 / 14 ms	110 / 120 ms
… mit network_id (ein Netz)	5 / 7 ms	5 / 7 ms
… mit type=manual_dhcp	7 / 8 ms	40 / 50 ms
… Suche nach Hostname-Präfix (q=h3-12)	14 / 17 ms	115 / 135 ms
… Suche nach MAC-Präfix	16 / 23 ms	131 / 145 ms
… sortiert nach Hostname, letzte Seite	20 / 33 ms	204 / 236 ms
PUT /addresses/{id} (Mittel aus 50)	5,0 ms	5,8 ms
Audit-Wachstum je Änderung	1,5 KiB	1,6 KiB

Der Höchstwert des Server-Speichers (235 MiB) stammt von den Anmeldungen (Argon2id mit 64 MiB je Hashberechnung), nicht von der Datenmenge. Jede Revision speichert alle erzeugten Dateien vollständig (komprimiert): Eine Revision nach 50 Änderungen ist so groß wie die erste.

Ergebnisse: BIND 9.20

Messgröße	5.000 Einträge	50.000 Einträge
Zonen / A- und PTR-Records	297 / 9.001	657 / 90.001
Zonendateien	0,6 MiB	5,4 MiB
Start bis alle Zonen geladen	0,07–0,08 s	0,35–0,43 s
named-RSS nach dem Laden / nach den Läufen	22 / 27 MiB	57 / 61 MiB
dnsperf maximal: Abfragen/s (Lauf 93 / Lauf 82)	68.200 / 69.400	51.600 / 72.000
… mittlere Latenz / verloren	2,2 ms / 0,08 %	2,2–3,2 ms / 0,1 %
… CPU von named	126–141 %	104–141 %
dnsperf bei 5.000 Abfragen/s: mittlere Latenz	0,2 ms	0,2–0,7 ms

Die Zonenzahl enthält 256 leere Reverse-Zonen des /16-Testnetzes. Der Durchsatz hängt kaum von der Zonengröße ab; die Grenze setzen die geteilten 4 Kerne, die Schwankung zwischen den Läufen kommt vom geteilten Runner.

Ergebnisse: Kea 3.2.1

Messgröße	5.000 Einträge	50.000 Einträge
Subnetze / Reservierungen	6 / 1.000	51 / 10.000
kea-dhcp4 -t (Prüfung beim Ausrollen)	0,08–0,13 s	0,36–0,39 s
Start bis DHCP4_STARTED	0,06–0,07 s	0,48–0,58 s
kea-dhcp4-RSS nach dem Start	20 MiB	42 MiB

Lauf 93, Werte je Zelle „klein / mittel“:

perfdhcp-Rate (Ziel)	DORA/s erreicht	Verluste Discover-Offer	mittlere Verzögerung Request-Ack	CPU Kea	RSS Kea	Lease-Datei kumuliert
250/s	250 / 250	0 % / 0 %	0,8 / 1,8 ms	29 / 31 %	22 / 44 MiB	0,2 MiB
500/s	500 / 500	0 % / 0 %	0,8 / 1,5 ms	56 / 61 %	24 / 46 MiB	0,4 MiB
750/s	750 / 717	0 % / 2,6 %	1,7 / 6,9 ms	83 / 89 %	26 / 47 MiB	0,6 MiB
1.000/s	1.000 / 795	0 % / 12,7 %	2,2 / 20 ms	117 / 112 %	28 / 48 MiB	0,8 MiB
1.500/s	1.050 / 781	17 % / 29 %	24 / 26 ms	153 / 137 %	31 / 49 MiB	1,0 MiB
2.000/s	917 / 690	33 % / 42 %	21 / 22 ms	171 / 141 %	33 / 51 MiB	1,3 MiB
4.000/s	503 / 284	65 % / 74 %	15 / 20 ms	165 / 116 %	36 / 50 MiB	1,5 MiB

In Lauf 82 erreichte Kea bei 1.000/s mit beiden Datensätzen 987 DORA/s (Verluste unter 1 %), bei 2.000/s rund 880 DORA/s.

Ergebnis: Auf 4 geteilten Kernen bedient Kea mit der erzeugten Konfiguration 750–1.000 vollständige Vergaben pro Sekunde ohne nennenswerte Verluste; mit 10.000 Reservierungen eher am unteren Ende. Darüber bricht der Durchsatz ein (Kea verwirft unter Überlast Pakete; Lastgenerator und Kea konkurrieren um dieselben Kerne). Zum Vergleich: 10.000 Clients mit einer Lease-Zeit von einer Stunde erneuern im Mittel rund 6 Leases pro Sekunde, ein gleichzeitiger Neustart aller 10.000 Clients dauert bei 750/s etwa 15 s. Die Lease-Datei wächst um rund 85 Byte je Vergabe oder Verlängerung und wird von Kea stündlich verdichtet (lfc-interval 3600 s).

Was nicht gemessen wurde (geschätzt)

• Speicher der Agents selbst (Go-Prozess, geschätzt 20–40 MiB je Agent) und des Servers mit 50 verbundenen Agents (je Agent ein gRPC-Stream; geschätzt wenige MiB zusätzlich).
• Parallele Benutzer der Oberfläche; die Latenzen oben gelten für eine Anfrage zur Zeit.
• Kea-HA (zwei Partner): Jede Vergabe wird zusätzlich an den Partner gemeldet; die Rate sinkt nach Kea-Handbuch spürbar. Mit HA ist von deutlich weniger als den gemessenen 750–1.000 DORA/s auszugehen.
• Speichermedium: Die Messung lief auf dem Speicher des Runners (vermutlich SSD). Auf SD-Karten sind PostgreSQL und die Kea-Lease-Datei deutlich langsamer.

5. Netzwerk

Verbindung	Richtung	Port	Pflicht
Weboberfläche und REST-API	Browser → Server	8443/tcp (HTTPS)	ja
Agent-Protokoll (gRPC, mTLS)	Agent → Server (ausgehend vom Agent)	8444/tcp	ja; auf dem Agent-Host muss kein Port für den Server offen sein
DNS-Abfragen	Clients → BIND	53/udp und 53/tcp	DNS-Agent
NOTIFY	Primary → Secondaries	53/udp (und tcp)	DNS-Cluster
Zonentransfer (AXFR/IXFR, TSIG)	Secondary → Primary	53/tcp	DNS-Cluster
Dynamische Updates (RFC 2136)	Domain Controller/Clients → Primary	53/udp und 53/tcp	dynamische Zonen
DHCP	Clients → Kea (Broadcast) bzw. Relay → Kea (Unicast)	67/udp	DHCP-Agent
DHCP-Antworten	Kea → Clients bzw. Kea → Relay	68/udp (Clients), 67/udp (Relay)	DHCP-Agent
DHCP-Relay	Router/Switch (ip helper-address) → Kea	67/udp	Netze ohne eigenen Kea im Segment
Kea-HA	Kea ↔ Kea, beide Richtungen	8001/tcp (ha_port je Cluster)	DHCP-Cluster mit zwei Servern
Lizenzprüfung	Server → license.beugsiud.de	443/tcp	ja (bei Ausfall 14 Tage Karenzzeit)
Installation von Kea	Agent-Host → dl.cloudsmith.io (ISC-Repository)	443/tcp	nur bei Installation/Upgrade mit --kea-source isc
Release-Download	Hosts → git.beugsiud.de	443/tcp	nur bei Installation/Upgrade (alternativ --from-dir)
Paketquellen der Distribution	alle Hosts → Spiegel	80/443/tcp	bei Installation/Upgrade
Zeitsynchronisation	alle Hosts → NTP-Server	123/udp	ja
PostgreSQL	Server → lokale Datenbank	Unix-Socket	ja (kein Netzport nötig)
rndc, Kea-Control-Socket	Agent → Dienst, lokal	127.0.0.1:953/tcp bzw. Unix-Socket	ja (nur lokal)
Monitoring	Prometheus → Server /metrics, /readyz	8443/tcp	optional, Zugriff begrenzen

Ports 8443 und 8444 sind in server.yaml (http.listen, agent_api.listen) bzw. in der Oberfläche (ha_port je DHCP-Cluster) änderbar. Wer Agents über NAT oder einen Proxy anbindet: Der Agent-Port braucht durchgehendes TLS (kein TLS-aufbrechender Proxy), die Adresse im Enrollment-Befehl kommt aus agent_api.public_address.

Zeitsynchronisation ist Pflicht

Zertifikate (14 Tage Laufzeit), TSIG (±5 Minuten), Lizenzprüfung (signierte Antworten höchstens 5 Minuten alt), TOTP (±30 s) und Kea-HA hängen an korrekten Uhren. Auf allen Hosts muss ein Zeitdienst laufen (systemd-timesyncd, chronyd oder ntpd). Der Installer warnt, wenn die Uhr nicht synchronisiert ist.

6. Raspberry Pi und andere ARM-Systeme

• Unterstützt ist 64-Bit-ARM (arm64/aarch64) mit einem 64-Bit-Betriebssystem (z. B. Raspberry Pi OS 64 Bit auf Debian-12-Basis, Ubuntu 24.04 für Raspberry Pi). 32-Bit-Systeme (armhf) nicht.
• Ein Raspberry Pi 4 oder 5 mit 2 GB (Agents) bzw. 4 GB (Server, klein) genügt nach den Messungen; für den Server mit 50.000 Adressen einen Pi 5 mit 8 GB oder eine VM wählen.
• SSD statt SD-Karte: PostgreSQL (Server), die Lease-Datei von Kea (jede Vergabe wird geschrieben), BIND-Journale dynamischer Zonen und die Journale von systemd schreiben laufend. SD-Karten verschleißen dadurch schnell und sind langsam. Für den Server ist eine SSD über USB 3 oder NVMe Pflicht, für Agents dringend empfohlen. Wo nur eine SD-Karte möglich ist: hochwertige Karte („High Endurance“), Storage=volatile oder eine Größenbegrenzung für journald, keine Swap-Datei auf der Karte.
• Ohne batteriegepufferte Uhr startet ein Pi mit falscher Zeit: Zeitsynchronisation vor dem Start der Dienste abwarten (systemd-time-wait-sync.service aktivieren), sonst schlagen TLS und TSIG bis zur Synchronisation fehl.

7. Plattenplatz-Planung

Was wächst, mit gemessenen Werten aus Abschnitt 4:

Was	Wachstum (gemessen)	Beispiel
Revisionen (Server)	0,7 MiB je Revision bei 5.000, 4,6 MiB bei 50.000 Adressen (alle Dateien jeder Revision, komprimiert gespeichert; davon 4,2 MiB Daten, der Rest Tabellen- und Indexaufwand)	50.000 Adressen, 10 Revisionen pro Arbeitstag: ≈ 46 MiB/Tag, ≈ 10 GiB/Jahr
Audit-Log (Server)	≈ 1,5–1,6 KiB je Änderung (vorher/nachher als JSON); ein Import erzeugt einen Eintrag je Zeile	1.000 Änderungen pro Tag: ≈ 0,5 GiB/Jahr
Adressen	≈ 0,4 KiB je Eintrag inkl. Indizes	50.000 Einträge: 20 MiB
Lease-Erfassung	erzeugt keine Audit-Einträge; Leases und dynamic-Einträge nur einmal je Adresse	vernachlässigbar
PostgreSQL-WAL, Sicherungen	WAL bis max_wal_size (Standard 1 GiB); Dumps etwa in Größe der Datenbank, komprimiert deutlich kleiner	Platz für mehrere Dumps einplanen
Agent: lokale Revisionen	die letzten 10 Revisionen der eigenen Rolle	50.000 Adressen: DNS ≈ 55 MiB, DHCP ≈ 15 MiB
BIND: Journale dynamischer Zonen	je nach Update-Rate, BIND verdichtet sie selbst	meist < 100 MiB
Kea: Lease-Datei	≈ 85 Byte je Vergabe/Verlängerung, stündlich verdichtet	10.000 Clients: wenige MiB
Logs (journald)	nach Konfiguration von journald	Standard: max. 10 % des Dateisystems

Aufbewahrung: Ohne Einstellung bleiben alle Revisionen und Audit-Einträge erhalten. Bei großen Datenbeständen und häufigem Ausrollen retention.revisions_keep (z. B. 200–500) und bei Bedarf retention.audit_days setzen (OPERATIONS.md §7); die neueste, die von Agents angewendeten und die offen ausgerollten Revisionen werden nie gelöscht. Mit revisions_keep: 500 bleiben bei 50.000 Adressen höchstens ≈ 2,3 GiB Revisionen.

Die Plattenempfehlungen in Abschnitt 3 (20 GB bzw. 50 GB für den Server) reichen damit für mehrere Jahre bei moderater Änderungsrate; bei täglich vielen Revisionen ohne Aufbewahrungsregel ist mit ≈ 10 GiB pro Jahr und 50.000 Adressen zu rechnen.

8. Sicherung, Wiederherstellung, Upgrade (Kurzfassung)

Einzelheiten in OPERATIONS.md.

• Sichern: PostgreSQL-Datenbank (pg_dump), den Master-Key /etc/ddi-suite/master.key (getrennt aufbewahren), /etc/ddi-suite/ und optional die Agent-Identitäten (/var/lib/ddi-suite/agent-<rolle>/identity/). CA- und Bundle-Schlüssel liegen verschlüsselt in der Datenbank und sind damit Teil des Dumps.
• Wiederherstellen: Server installieren, Master-Key und Konfiguration zurücklegen, Dump einspielen, Server starten; Agents verbinden sich wieder. Ohne Master-Key sind alle Geheimnisse verloren (CA, TSIG, HA-Passwörter): dann neu aufbauen und Agents neu registrieren.
• Upgrade: erst den Server (install.sh --upgrade, Migrationen laufen beim Start), dann die Agents. Vorher die Datenbank sichern. DNS und DHCP laufen während eines Upgrades weiter.