Studios in MotionProjektkartei

Betriebssicherung und Backups

Aktiv

Tägliche verschlüsselte Backups, wöchentlicher Restore-Test, Repo-Sync- und Dienste-Wächter, Deploy-Protokoll mit Rollback, Sicherheitsvorfälle und offene Härtungsmaßnahmen

Bereich
Betrieb
Start
20.07.2026
Zuletzt
10.10.2026
Am Zug
René
Nächster Schritt, René

Backup-Kopie außer Haus (Hetzner Storage Box) beschaffen und einrichten, dann Hetzner-Firewall klären und SSH und Coolify härten

Zentrale: Betrieb › Deploys

Worum es geht

Das Kernsystem (Hub, Dienste, Datenbanken, Ticketsystem, Content-Service) läuft auf einer einzigen Maschine mit rund 30 Containern. Diese Akte sammelt, was Daten sichert, Ausfälle sichtbar macht, Deploys rückholbar macht und welche Sicherheitslücken noch offen sind. Backups verhindern keinen Ausfall, sie begrenzen den Datenverlust.

Stand

  • Tägliches verschlüsseltes Backup tools/backup_ops.sh (gpg AES256) via sim-ops-backup.timer um 03:33 UTC: hub.db, assistant.db, ads.db, post.db, content.db, Postgres-Dumps (Ticketsystem, Coolify), Ticket-Uploads, Content-Assets, Lead-Dateien. Ziel Hetzner-Volume /mnt/HC_Volume_105805516, lokal 2 Stände. Aufbewahrung seit 06.10. 14 Tage, Tagesarchiv rund 1,5 GB (11.10. geprüft).
  • Wöchentlicher Restore-Test (sim-restore-test.timer, sonntags 05:00 UTC): spielt in einen Wegwerf-Container zurück und vergleicht gegen Live. Letzter Lauf laut Timer 11.10.
  • Repo-Sync-Wächter (täglich 04:10 UTC), Backup-Alters-Wächter (Telegram bei über 30 h), Dienste-Health im Hub (8 Ziele, alle 10 min), Coolify-Deploy-Poller und GitHub-Workflow-Poller (alle 15 min), Headless-Chromium-Wächter.
  • Deploy-Protokoll mit Nachprüfung und Rollback (Hub v0.304.0, 15.09.): rollout.sh mit Sperre, Image-Tags, Protokoll im Hub (Zentrale › Betrieb › Deploys), Rollback-Knopf mit Wächter alle 30 s. Code geht zurück, Daten nicht.
  • SSH: Passwort-Login abgeschaltet (Datei /etc/ssh/sshd_config.d/50-kein-passwort-login.conf), fail2ban aktiv (sshd 15 min, recidive 1 Woche, ignoreip enthält 10.0.0.0/8 wegen Coolify).
  • Server aufgerüstet (22 GB RAM, 451 GB Platte), Swap und earlyoom aktiv; Security-Updates laufen über unattended-upgrades.

Offen

  • René Hetzner Storage Box für B2 bereitstellen (Zugang vom Server aus nicht löschbar), bisher verlässt keine Backup-Kopie den Server.
  • René Hetzner-Cloud-Firewall klären (nc -vz 178.104.9.3 5432), blockiert den Firewall-Schritt S9.
  • René Coolify-2FA für beide Benutzer (S3).
  • René SSH-Härtung (S4, 67 Passwort-Logins pro Woche zum Zeitpunkt der Prüfung, Aussperr-Gefahr), Reboot für Kernel (S8).
  • René sim-ops main pushen (Wiederherstellung 95376f6 aus dem Vorfall vom 10.10. und weitere lokale Commits), Push erst prüfen, dann eigener Befehl.
  • René Rotation der Zugänge laut Rotations-Liste; Secdata: Proxy-Host des Content-Agenten aus dem öffentlichen NPM nehmen oder Passwort rotieren, Quarantäne-Ordner nach Sichtung löschen.
  • ich Backup-Umbau (Fotos und Uploads inkrementell statt Vollkopie), Speicherlimits der Hermes-Container in Coolify.
  • ich Postgres vom Netz nehmen (S2, Port ist tragend, DB_HOST=10.0.5.1, braucht Wartungsfenster), Hermes-Port 9030 schließen (S7).
  • ich Wiederanlauf einmal üben und Notfallblatt außerhalb des Servers (A1, A2); tools/vorschau.sh (K3) wartet auf Renés Entscheidung.

Entscheidungen und Regeln

  • 2026-07-20: Nach jedem Commit git push origin main; .env* und data/ nie committen; vor Pushes Secrets-Check.
  • 2026-07-23: Wächter für Dateisystem laufen als Host-Skripte in sim-ops/tools/ und melden per POST /api/events.
  • 2026-08-12: Nur Vorschläge und was stressfrei machbar ist; Renés Dynamik-IPs bewusst nicht in fail2ban gewhitelistet.
  • 2026-09-27: docker exec nie mit Glob /**, immer timeout im Container (RAM-Ausreißer 8 GB).
  • 2026-10-06: Backup-Aufbewahrung 14 Tage (René: reicht).
  • 2026-10-10: Git nie mit cd in einer Pipe-Kette; immer git -C, Push als eigener Befehl nach Prüfung, bei sim-ops nie git add -A.
  • Hub-Deploy nur über cd /root/sim-ops/deploy && ./rollout.sh; Versionsbump an drei Stellen.
  • Postgres meldet fehlgeschlagene Anmeldungen immer; log_connections bewusst nicht gesetzt.

Verlauf

  1. Vorfall: cd in Pipe-Kette führte zu Commit 1842b6d und Push in sim-ops, Coolify baute ads-service mit unfertiger 0.4.0; Wiederherstellung 95376f6 lokal, Push offen.
  2. Backup-Aufbewahrung auf 14 Tage (532d29e), RAM-Ausreißer von 27.09. beendet, Volume 91 % auf 61 %.
  3. RAM-Ausreißer durch docker exec mit Glob im Content-Container (8 GB, Swap voll).
  4. Lead-Dateien im Backup (fc11c52).
  5. Deploy-Protokoll, Nachprüfung, Rollback (ad7018b, Hub v0.304.0).
  6. Deploy ohne Lücke (rollout.sh, Hub v0.245.14).
  7. SecData: Krypto-Miner im Hermes-Container seit 10.07., entschärft, Quarantäne.
  8. Sicherheits- und Ausfallprüfung; Ticket-Postgres und Coolify-DB im Backup, Restore-Test wöchentlich (fb29492), fail2ban.
  9. GitHub-Workflow-Poller (V4 komplett).
  10. Betriebssicherheit V2 bis V4 (Hub v0.33.0), post.db im Backup.
  11. content.db und Content-Assets im Backup.
  12. Daten-Backup eingerichtet.

Wo liegt was

  • Skripte /root/sim-ops/tools/: backup_ops.sh, backup_audit.sh, restore_test.sh, repo_sync_watch.sh, coolify_deploy_poll.sh, github_workflow_poll.sh, headless_watch.sh, RESTORE.md (Restore-Anleitung).
  • Deploy: /root/sim-ops/deploy/ (rollout.sh, rollback.sh, rollback-waechter.sh, nachpruefung.sh, README-deploy.md, Sperrdatei deploy/SPERRE, Protokoll deploy/log/deploys.jsonl); Hub: systemDeploysCore.ts, systemDeploys.ts, Tabellen deploys, rollback_anfragen.
  • Timer (systemd): sim-ops-backup, sim-repo-sync, sim-restore-test, sim-coolify-deploy, sim-github-workflow, sim-rollback-waechter, sim-agentconfigs, sim-headless-watch, sim-wiki-autopull.
  • Backups: /mnt/HC_Volume_105805516/backups/sim-ops/; Passphrase außerhalb des Repos unter /root/.sim_ops_backup/ und in Renés Passwort-Manager.
  • Vorfallnotiz: /root/transfer/VORFALL-secdata-miner-20260827.md. Wiki: 50-Strategien/Gesamtsystem/Offene Massnahmen Sicherheit und Betrieb.md (Arbeitsvorrat), Vault-Seite Sicherheits- und Ausfallprüfung 2026-08-12.