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 GitLab — gibt es Änderungen, die Handarbeit verlangen? Manuelle Migrationen?
  3. Update einspielen: 
    cd /var/www/etb
git fetch --tags
git checkout v4.9.5     # 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 Umstellung auf einen einheitlichen Namen 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.

ℹ️ Update auf den Meldungs-Bus: Hier legt der Schema-Check acht neue Tabellen an — sechs für den Bus (user_loeschgruppe, meldung_arten, meldung_regeln, meldungen, meldung_zustellungen, meldung_kanal_ziele) und zwei für Web Push (push_abos, push_einladungen). Dazu spielt er den Meldungskatalog samt Startvorlagen ein, ergänzt die Rolle Einsatzkraft und trägt das neue Recht „Nachricht verschicken" (mitteilung.durchsage) für alle Rollen nach, die schon „Alarm manuell auslösen" haben.

An der Alarmierung ändert sich dabei nichts: Die Chat-IDs aus der .env gelten als Rückfall weiter, es geht dieselbe Nachricht in denselben Chat. Erst danach kannst Du unter Meldungen in Ruhe auf eigene Zuordnungen umstellen.

Vor dem Schema-Check protokolliert der Bus nichts und die Seite das Postfach bleibt leer — der laufende Betrieb ist davon nicht betroffen.

⚠️ Web Push kommt nicht von selbst. Der Zustellweg bleibt nach dem Update auf Telegram stehen; die neuen Tabellen sind nur die Voraussetzung. Umgestellt wird bewusst von Hand — und erst, wenn genug Geräte eingerichtet sind. Der Weg dahin steht unter Web Push. Voraussetzung dafür ist eine Instanz unter HTTPS; ohne Zertifikat sperrt jeder Browser die Benachrichtigungen.

ℹ️ Update auf den Rückkanal: Hier legt der Schema-Check keine neue Tabelle an, sondern acht Spalten (Antwort-Ausweis und Zusatztext an den Zustellungen, vier für die Sammelmeldung, der Meldungsbezug der Telegram-Antworten und der Besitznachweis der Geräte) sowie zwei Indizes. Außerdem trägt er die beiden neuen Meldungsarten Sammelmeldung und Freie Nachricht samt Startvorlagen nach.

Vor dem Lauf lassen sich Rückmeldungen aus der App und vom Sperrbildschirm nicht speichern, es gibt keine Sammelmeldung und die Seite Nachricht verschickt nichts. Alarmierung und Rückmeldungen aus dem Telegram-Chat laufen unverändert weiter.

Danach zwei Dinge prüfen:

  1. Wer die Seite Rückmeldungen braucht, hat jetzt admin.access nötig — vorher genügte eine Anmeldung.
  2. Wer eine Nachricht verschicken darf, steht in Rollen & Rechte (mitteilung.durchsage).

ℹ️ Update auf Postfach und Profil: Der Schema-Check ergänzt zwei Spalten an den Geräten (push_abos.freigegeben_at für die Freigabe, push_abos.letzter_empfang für den Empfangsnachweis), trägt das Recht „Rückmeldungen anderer sehen" (mitteilung.rueckmeldungen) für alle Rollen nach, die schon „Nachricht verschicken" haben, ergänzt die Meldungsart „Neues Gerät angemeldet" und markiert einmalig alle bereits angemeldeten Geräte als freigegeben.

Vor dem Lauf stellt das ETB weiter an alle Geräte zu (ausdrücklicher Rückfall — eine unalarmierte Wehr wäre schlimmer), aber die Geräte-Freigabe wirkt nicht und die Bereitschaftsanzeige bleibt leer. Danach prüfen: die Verteilung des neuen Rechts im Rollen-Editor, falls „Nachricht verschicken" bei Euch abweichend vom Standard vergeben ist.

ℹ️ 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 v4.9.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?