Betrieb & Installation

Backup & Updates

So sicherst Du Deine Daten und spielst neue ETB-Versionen ein.

Was Du sichern musst

Drei Sachen, alle drei zusammen — sonst sind die Daten nicht wiederherstellbar:

  1. Datenbank — alle Einsätze, Schwerpunkte, User, Konfiguration.
  2. storage/uploads/ — Anhänge in Kommentaren (Bilder, PDFs, Sprachnachrichten).
  3. public/branding/ — Dein hochgeladenes Logo und Favicon.

config/.env mit den DB-/Mail-/Telegram-Zugangsdaten ist sicherheitskritisch. Sichere die separat und verschlüsselt — am besten in Deinem Passwort-Manager, nicht im selben Backup wie der DB-Dump.

DB-Dump

mysqldump --single-transaction \
          --quick \
          --routines \
          -u etb_user -p etb_db \
          | gzip > etb-$(date +%Y%m%d-%H%M).sql.gz

--single-transaction sorgt dafür, dass das Backup einen konsistenten Snapshot kriegt, ohne die Tabellen zu locken — der Live-Betrieb läuft weiter.

Storage-Backup

tar czf etb-uploads-$(date +%Y%m%d-%H%M).tar.gz \
    /var/www/etb/storage/uploads \
    /var/www/etb/public/branding

Backup-Frequenz

Empfehlung:

  • DB-Dump: täglich nachts, 7 Tage rotieren
  • Storage-Backup: täglich oder wöchentlich, je nach Anhang-Volumen
  • .env: einmal nach jedem Setting-Change in den Passwort-Manager

Für Profis: ein wöchentlicher Vollbackup + tägliche inkrementelle Backups via rsnapshot o. ä.

Restore — der Ernstfall

  1. Frische DB anlegen, dann: 
    zcat etb-20260524-0300.sql.gz | mysql -u etb_user -p etb_neu
  2. storage/-Backup zurückspielen: 
    tar xzf etb-uploads-20260524-0300.tar.gz -C /
  3. config/.env aus dem Passwort-Manager wiederherstellen, ggf. DB-Name anpassen.
  4. Webserver konfigurieren, Cron neu setzen.
  5. Test-Login, Test-Mail, alles okay.

⚠️ Achtung: Nach dem Restore unbedingt einmal als Admin einloggen und /admin/system-status.php checken. Wenn etwas nicht passt, siehst Du es dort sofort.

Updates einspielen

Updates kommen über git pull auf das Repo. Vor jedem Update:

  1. Backup machen (DB + Storage).
  2. Release-Notes lesen auf der CHANGELOG / Releases auf GitHub — gibt es Breaking Changes? Manuelle Migrationen?
  3. Update einspielen: 
    cd /var/www/etb
git fetch --tags
git checkout v2.0.0     # gewünschter Release-Tag
  4. Schema-Migration: Beim nächsten Browser-Aufruf einer beliebigen Admin-Seite zeigt das ETB einen Schema-Banner, wenn neue Tabellen anzulegen sind. Klick auf „→ Jetzt anlegen" — fertig. Oder gehe direkt auf /admin/schema-check.php.
  5. System-Status prüfen: /admin/system-status.php — alles grün?
  6. Test-Lauf: Test-Mail schicken, prüfen ob ein Einsatz daraus wird.

⚠️ Ein Update kann alle Nutzer einmalig abmelden. Mit der Entmandantisierungs-Etappe wurde der interne Sitzungs-Cookie umbenannt (FFWAC_SID → FFETB_SID). Beim ersten Update über diesen Stand hinweg werden deshalb alle laufenden Sitzungen ungültig — jeder muss sich danach einmal neu anmelden. Das ist gewollt und kein Defekt; passwortlos wird niemand ausgesperrt, nur einmal neu eingeloggt. Plane das Update entsprechend (nicht mitten in einer Lage).

ℹ️ Schema-Check nach jedem Update ausführen. Updates bringen oft neue Tabellen und Spalten mit, die der Schema-Check anlegt. Dieses Release z. B. bringt u. a. den Stichwort-Katalog, temporäre Einsatz-Rollen, die manuelle Alarm-Auslösung und den Alarm-Knopf mit — der Schema-Check legt die zugehörigen Tabellen (stichwort_katalog, alarm_einsatz_trigger, alarm_trigger_throttle, alarm_role_offer) und Spalten (an einsaetze z. B. erledigt_by/erledigt_at/stichwort_katalog_id, an users die temp_role…-Spalten, an alarm_rule manual_address_mode/manual_strasse/manual_ort sowie temp_role_offer/temp_role_offer_hours) an und rüstet die neuen Default-Rechte nach (user.assign_temp_role, alarm.trigger_manual). Bis das migriert ist, läuft die App grundsätzlich weiter — die neuen Funktionen greifen aber erst danach, und der Schema-Banner bleibt sichtbar, bis Du auf „Reparieren" geklickt hast.

ℹ️ Tipp: Spiele Updates immer außerhalb der Stoßzeiten ein — sonntags morgens ist meist ruhig. Bei einer aktiven Lage nicht upgraden.

Rolling Back

Falls ein Update Probleme macht:

cd /var/www/etb
git checkout v1.5.0    # vorheriger Release-Tag

Bei DB-Schema-Änderungen (selten, aber möglich): DB-Dump von vor dem Upgrade einspielen. Deshalb der nachdrückliche Hinweis oben: Backup vor Upgrade.

Sicherheits-Updates

PHP, MySQL, OS-Updates: ganz normal regelmäßig einspielen. Das ETB hat keine harten Versions-Anforderungen außer „PHP 8.1+" — wenn Dein PHP zu alt wird, kriegst Du beim Browser-Aufruf eine entsprechende Fehlermeldung.

Was als nächstes?