Skip to main content

Datenbank-Infrastruktur

1. Zweck der Datenbank-Infrastruktur

Diese Dokumentation beschreibt den aktuellen Stand des zentralen MariaDB-Datenbankservers im Heimnetz.

Der Fokus liegt auf:

  • Datenintegrität

  • Wiederherstellbarkeit (Disaster Recovery)

  • klaren Betriebsprozessen

Hochverfügbarkeit (HA) ist bewusst noch nicht umgesetzt, aber architektonisch vorbereitet und später geplant.

2. Architekturüberblick

2.1 Grundprinzip

  • Ein dedizierter Datenbankserver

  • Lokale, performante Datenspeicherung

  • Externe, konsistente Backups auf NAS

  • Keine direkte Internet-Exponierung

2.2 Logische Architektur



[ Anwendungen ] (Nextcloud, Vaultwarden, BookStack, …) | | TCP 3306 (intern) | [ MariaDB Server ] | | mariabackup / Binlogs | [ NAS (SMB, nur Backups) ]

3. Systemdaten

Komponente Wert
Betriebssystem Debian 12
Virtualisierung Proxmox VM
Ressourcen 2 vCPU / 4 GB RAM
Datenbank MariaDB (LTS)
DB-Datenpfad /var/lib/mysql
Backup-Ziel NAS via SMB

4. Sicherheits- und Designentscheidungen

4.1 Bewusste Entscheidungen

  • Single Node statt HA (vorerst)

  • Lokales Storage für produktive DB-Daten

  • NAS ausschließlich für Backups

  • Kein Reverse Proxy für MySQL

  • Kein offener DB-Port ins Internet

4.2 Zugriff

  • Anwendungen greifen nur intern auf die DB zu

  • Externer Zugriff (falls notwendig) ausschließlich über Tunnel (z. B. WireGuard / Reverse-SSH)

5. MariaDB-Konfiguration (relevant)

5.1 Wichtige Parameter



[mysqld] server-id = 1 bind-address = 0.0.0.0 innodb_buffer_pool_size = 2G innodb_log_file_size = 512M log_bin = /var/log/mysql/mysql-bin binlog_format = ROW expire_logs_days = 7 sync_binlog = 1 innodb_flush_log_at_trx_commit = 1 skip-name-resolve

5.2 Bedeutung

  • Binary Logs aktiv → Point-in-Time-Recovery (PITR)

  • ROW-Format → höchste Konsistenz

  • Crash-sichere Writes → Datensicherheit vor Performance

6. Backup-Strategie (Kernbestandteil)

6.1 Grundsätze

  • VM-Snapshots sind kein Ersatz für DB-Backups

  • Backups müssen:

    • konsistent

    • extern

    • automatisiert

    • wiederherstellbar sein

6.2 Backup-Arten

A) Full-Backup

  • Tool: mariabackup

  • Physisches, konsistentes Backup

  • Restorefähig nach --prepare

B) Binary Logs

  • Ermöglichen Wiederherstellung bis zu einem exakten Zeitpunkt

  • Werden separat archiviert

  • Ergänzen das Full-Backup (PITR)

7. Backup-Zeitplan

Typ Zeitpunkt
Full-Backup Jeder zweite Sonntag, 03:00 Uhr
Binlog-Sicherung Täglich, 04:00 Uhr

Die Full-Backups laufen bewusst seltener, da Binlogs eine fein granularere Wiederherstellung erlauben.

8. Backup-Speicherstruktur (NAS)



/mnt/nas/mysql-backups/ ├── full/ │ ├── YYYY-MM-DD/ │ └── … ├── binlogs/ │ ├── mysql-bin.000001 │ ├── mysql-bin.000002 │ └── mysql-bin.index ├── logs/ │ ├── full-backup.log │ └── binlog-sync.log └── metadata/ └── latest_full.txt

9. Retention (Aufbewahrung)

Backup-Typ Aufbewahrung
Full-Backups 42 Tage
Binlogs 42 Tage
Logs nach Bedarf

Die Retention ist so gewählt, dass immer mindestens ein vollständiger Restore-Pfad vorhanden ist.

10. Restore-Szenarien

10.1 Full Restore (Totalschaden)

  1. MariaDB stoppen

  2. /var/lib/mysql leeren oder sichern

  3. Letztes Full-Backup zurückkopieren

  4. Rechte setzen (mysql:mysql)

  5. MariaDB starten

  6. Daten prüfen

10.2 Point-in-Time-Recovery (PITR)

  1. Full Restore durchführen

  2. Zielzeitpunkt definieren

  3. Binlogs bis zu diesem Zeitpunkt einspielen:



mysqlbinlog \ --stop-datetime="YYYY-MM-DD HH:MM:SS" \ /mnt/nas/mysql-backups/binlogs/mysql-bin.* | mysql

11. Betriebsstatus

Aktueller Stand:

  • Backups erfolgreich getestet

  • Binlogs werden täglich gesichert

  • Restore-Pfad dokumentiert

  • System produktionsbereit

12. Ausblick / Weiterentwicklung

Geplant (nicht umgesetzt):

  • MariaDB-HA (Primary / Replica)

  • Proxy + VIP für DB-Zugriffe

  • Backup-Quelle auf Replica verlagern

  • Monitoring und Alarmierung

Die aktuelle Architektur ist HA-fähig, ohne dass bestehende Komponenten ersetzt werden müssen.

13. Aktueller Fokus

Der aktuelle Fokus liegt auf:

  • sauberer Migration aller Anwendungen

  • Validierung der Backups nach Migration

  • Stabilisierung des Betriebs

No comments to display

Back to top