Zeiterfassung auf eigenem Server: Kapazität richtig planen

Das Problem: Überdimensioniert oder chronisch überlastet

Sie betreiben Zeiterfassung auf eigener Infrastruktur, weil Sie Kontrolle über Personendaten behalten wollen. Doch wie viel CPU, RAM und Storage braucht das System tatsächlich? Zu knapp dimensioniert, und morgens beim Einstempeln hängt die Weboberfläche. Zu großzügig, und Sie zahlen Monat für Monat für ungenutzte Kerne und Gigabyte. Viele mittelständische IT-Leiter greifen zur Heuristik „doppelte Nutzerzahl gleich doppelte vCPUs”, landen damit bei Vier-Kern-Maschinen für dreißig Mitarbeitende und fragen sich, warum der Hypervisor 80 Prozent Idle meldet.

Das zweite Szenario ist unangenehmer: Sie starten mit zwei vCPUs und 4 GB RAM, weil „Zeiterfassung ja nur Stempeldaten schreibt”. Nach einem Jahr kommen Projektzeitauswertungen, Export nach DATEV und automatische Monatsberichte hinzu. Plötzlich rennt die Datenbank in Swaps, Backups dauern drei Stunden, und Benutzer beschweren sich über Ladezeiten von acht Sekunden. Dieser Artikel zeigt, wie Sie die Kapazität von Anfang an realistisch kalkulieren, welche Metriken Sie überwachen müssen und wann Nachsteuerung sinnvoll ist.

Definition: Was „Kapazität” bei Zeiterfassung bedeutet

Kapazität gliedert sich in drei Dimensionen:

• CPU: Anzahl virtueller Kerne, Taktfrequenz. Zeiterfassung ist transaktionslastig beim Stempeln, rechenlastig bei Auswertungen und Reports.
• RAM: Arbeitsspeicher für Datenbankpuffer, Application Server, Caching. Zu wenig RAM zwingt das System auf Festplatte aus (Swap), was Latenz um Faktor zehn erhöht.
• Storage: IOPS und Durchsatz für Datenbank-Write bei jedem Stempelvorgang, Speicherplatz für Audit-Log und Backups über Jahre hinweg.

Dazu kommen Netzwerk-Bandbreite, wenn viele Mitarbeitende gleichzeitig mobile Apps synchronisieren, und Backup-Fenster, wenn Sie nachts Snapshots auf NAS oder Object-Storage ziehen.

Schritt 1: Nutzerzahl und Stempelhäufigkeit erfassen

Beginnen Sie mit harten Zahlen:

1. Mitarbeitendenzahl heute und in zwei Jahren: Wenn Sie 120 Mitarbeitende haben und in 18 Monaten auf 180 wachsen wollen, dimensionieren Sie für 200.
2. Stempelrate: Klassische Büromitarbeitende stempeln zwei Mal am Tag (Kommen, Gehen), Schichtbetrieb vier bis sechs Mal (Pausenbeginn, Pausenende). Projekterfassung kann zehn Buchungen pro Tag bedeuten.
3. Spitzenlast: Morgens zwischen 07:00 und 08:00 Uhr stempeln 60 bis 80 Prozent innerhalb von 15 Minuten. Das sind bei 150 Mitarbeitenden rund 120 Requests in 900 Sekunden, also 0,13 Requests pro Sekunde im Durchschnitt, aber in Wirklichkeit Burst-Peaks von zwei bis drei Requests pro Sekunde.

Notieren Sie diese Zahlen in einer Tabelle. Fügen Sie 20 Prozent Puffer für Urlaubsrückkehrer, Krankheitsvertretungen und Feiertage mit verschobenen Stempeln hinzu.

Schritt 2: CPU-Bedarf kalkulieren

Eine Stempelbuchung besteht typisch aus:

• HTTP-Request an den Application Server (Node.js, PHP, Python, Go)
• SQL-Insert in die Datenbank (PostgreSQL, MariaDB, MySQL)
• Audit-Log-Eintrag (zweiter Insert oder File-Append)
• Response an den Client

Moderne Application-Server verarbeiten einfache Inserts mit 50 bis 100 Requests pro Sekunde pro vCPU, wenn die Datenbank auf separater Maschine läuft. Bei Burst-Peaks von drei Requests pro Sekunde reicht theoretisch ein Kern. Doch Sie betreiben selten nur Zeiterfassung: Auswertungen, CSV-Exporte, PDF-Reports und Datenbank-Backups beanspruchen CPU parallel.

Faustregel für kombinierte Maschine (App plus Datenbank):

• Bis 50 Mitarbeitende: 2 vCPUs
• 51 bis 150 Mitarbeitende: 4 vCPUs
• 151 bis 300 Mitarbeitende: 4 bis 6 vCPUs

Planen Sie einen zweiten Kern ausschließlich für Hintergrund-Jobs (nächtliche DATEV-Exporte, Monatsreports). Wenn Sie komplexe SQL-Aggregationen fahren (Projektzeiten über Abteilungen hinweg), addieren Sie einen weiteren Kern.

Schritt 3: RAM richtig bemessen

RAM zerfällt in:

• Betriebssystem: 512 MB bis 1 GB für Linux (Debian, Ubuntu Server)
• Application Server: 512 MB bis 2 GB, abhängig von Framework und Pooling
• Datenbankpuffer: PostgreSQL shared_buffers empfohlen bei 25 Prozent des Gesamt-RAM, MySQL innodb_buffer_pool_size ähnlich

Beispielrechnung für 150 Mitarbeitende:

• OS: 1 GB
• Application Server (Node.js mit PM2, vier Worker): 2 GB
• PostgreSQL shared_buffers: 2 GB (entspricht 8 GB Gesamt-RAM × 25 Prozent)
• OS-Cache und Swap-Reserve: 3 GB

Summe: 8 GB. Damit bleiben Sie unter Normallast bei 60 bis 70 Prozent RAM-Auslastung und haben Puffer für nächtliche Reports oder gleichzeitige Exporte.

Reduzieren Sie auf 4 GB nur, wenn Sie wirklich unter 50 Mitarbeitenden bleiben und keinerlei Auswertungen parallel laufen. Erhöhen Sie auf 16 GB, sobald Sie Business-Intelligence-Dashboards anbinden oder Data-Warehouse-Exporte bauen.

Schritt 4: Storage-Anforderungen und IOPS

Zeiterfassung schreibt wenig Daten pro Stempel: 200 bis 500 Byte pro Buchung. Bei 150 Mitarbeitenden und vier Stempeln pro Tag sind das 600 Inserts täglich, rund 180 kB reine Nutzdaten. Dazu kommen Indizes, Audit-Log und Wachstum über Jahre.

Speicherplatz-Kalkulation über drei Jahre:

• 150 Mitarbeitende × 4 Stempel/Tag × 250 Arbeitstage × 3 Jahre = 450.000 Buchungen
• 450.000 × 500 Byte = 225 MB Rohdaten
• Indizes (B-Tree auf Mitarbeiter-ID, Timestamp): Faktor 1,5 → 338 MB
• Audit-Log (jede Änderung doppelt): Faktor 2 → 675 MB
• Backup-Snapshots (täglich, 30 Tage Retention): 675 MB × 30 = 20 GB

Summe: 25 GB inkl. OS und Anwendungscode. Planen Sie 50 GB SSD, damit Sie Spielraum für Logs, temporäre Exporte und unvorhergesehene Reports haben.

IOPS: Stempelspitzen erzeugen zwei bis drei Writes pro Sekunde. Eine Consumer-SSD schafft 10.000 IOPS, Enterprise-NVMe 50.000 IOPS. Storage ist hier kein Engpass, solange Sie nicht auf Netzwerk-NAS mit Gigabit-Uplink und Hunderten Clients gleichzeitig zugreifen. Für lokale VM-Datastores auf SSD reichen Standard-SATA-SSDs aus.

Schritt 5: Netzwerk und Backup-Fenster

Mobile Apps synchronisieren Offline-Buchungen beim Wiederherstellen der Verbindung. Wenn zwanzig Außendienstler montags ihre Wochenbuchungen hochladen, entstehen 200 bis 300 Requests in kurzer Zeit. Prüfen Sie, ob Ihre Firewall-Regel und der Load-Balancer genug Concurrent Connections zulassen (typisch 1024 ist Standard, selten der Engpass).

Backups laufen idealerweise nachts. Ein pg_dump von 700 MB dauert auf SSD zehn bis fünfzehn Sekunden, Kompression und Transfer auf NAS weitere zwei Minuten. Damit liegt das Backup-Fenster unter fünf Minuten. Halten Sie trotzdem ein einstündiges Wartungsfenster zwischen 02:00 und 03:00 Uhr frei, in dem auch DATEV-Exporte und Report-Jobs laufen dürfen.

Schritt 6: Monitoring und Alerting einrichten

Kapazitätsplanung endet nicht mit dem ersten Deploy. Überwachen Sie:

• CPU-Auslastung (fünf Minuten Mittelwert): Alarm bei über 75 Prozent über 15 Minuten
• RAM-Nutzung: Alarm bei über 85 Prozent, kritisch wenn Swap aktiv wird
• Disk I/O Wait: über 10 Prozent deutet auf Storage-Bottleneck
• Datenbankverbindungen: PostgreSQL max_connections Standard 100, Alarm bei über 80 genutzten Connections

Tools wie Prometheus mit Grafana, Netdata oder Checkmk liefern vorgefertigte Dashboards. Richten Sie E-Mail- oder Mattermost-Alerts ein, damit Sie Engpässe erkennen, bevor Benutzer sich melden.

Schritt 7: Wann und wie Sie nachskalieren

Drei Szenarien erfordern Anpassung:

1. Wachstum über Plan: Sie hatten 150 Mitarbeitende kalkuliert, nach einem Jahr sind es 220. CPU-Last steigt von 40 auf 65 Prozent. Erhöhen Sie von vier auf sechs vCPUs und RAM von 8 auf 12 GB.
2. Neue Funktionen: Projektzeit-Auswertung mit komplexen Joins, automatische PDF-Reports. Dedizieren Sie zwei vCPUs und 4 GB RAM auf separater Worker-VM.
3. Gesetzliche Anforderungen: Audit-Log-Retention steigt von zwei auf zehn Jahre. Storage wächst um Faktor vier. Migrieren Sie Datenbank auf zweite Disk oder erweitern Sie Volume um 100 GB.

Moderne Hypervisor (Proxmox, VMware ESXi, KVM) erlauben Hot-Add von CPU und RAM. Datenbank-Downtimes für Storage-Erweiterung liegen unter fünf Minuten, wenn Sie Logical Volumes (LVM) nutzen.

Was nicht funktioniert

• „Wir verdoppeln alles zur Sicherheit”: Sie zahlen doppelte Lizenzkosten, doppelte Energie, doppelte Backup-Kapazität, ohne Nutzen.
• Keine Monitoring-Daten sammeln: Ohne Metriken erraten Sie Engpässe, statt sie zu messen.
• Single Point of Failure: Zeiterfassung ist lohnrelevant. Betreiben Sie RAID für Storage, tägliche Backups und einen zweiten Standby-Server, wenn Ausfall teurer ist als Hardware.
• Billiges Shared-Hosting mit geteilten CPU-Kernen: Stempelspitzen kollidieren mit anderen Mandanten, Latenz springt auf Sekunden.

Realistische Erwartungen

Ein korrekt dimensionierter Server für 150 Mitarbeitende kostet als VM auf eigenem Hypervisor rund 60 bis 80 Euro pro Monat (anteilig Hypervisor, Strom, Wartung) oder 120 bis 150 Euro als Managed vServer bei Hetzner oder Netcup. Antwortzeiten für Stempelvorgänge liegen unter 200 Millisekunden, Auswertungen unter zwei Sekunden, nächtliche Exporte unter fünf Minuten. Sie behalten volle Kontrolle über Personendaten, erfüllen DSGVO-Anforderungen an EU-Hosting und können bei Bedarf jederzeit nachskalieren.

Fazit und nächster Schritt

Kapazitätsplanung für Zeiterfassung ist keine Raketenwissenschaft, erfordert aber ehrliche Zahlen zu Nutzern, Stempelhäufigkeit und geplanten Auswertungen. Beginnen Sie mit vier vCPUs, 8 GB RAM und 50 GB SSD für 100 bis 150 Mitarbeitende, überwachen Sie CPU, RAM und IOPS kontinuierlich und skalieren Sie nach, sobald Metriken über 75 Prozent klettern. Wenn Sie unsicher sind, welche Dimension bei Ihrem Lastprofil zuerst zum Engpass wird, oder Sie Self-Hosted-Zeiterfassung mit DATEV-Anbindung aufsetzen wollen: Lassen Sie uns die Zahlen gemeinsam durchrechnen und die Infrastruktur so planen, dass sie wächst, ohne nachts Alarme auszulösen.

Sprechen Sie mit uns

Sie möchten das in Ihrem Betrieb umsetzen? Wir bauen die passende Maschine mit Ihnen.

Telefon: 040 468 967 680
E-Mail: info@whitefox-automations.com
Oder über unser Kontaktformular.