[inhalt]
Projekt BISO 3 - Handbuch

Backup- und Restore-Konzept

English Version

Übersicht

Eine BISO-Installation besteht aus drei logisch unabhängigen Bereichen, die getrennt gesichert und wiederhergestellt werden müssen:

Bereich Pfad / Quelle Inhalt
Webroot <biso-webroot> PHP-Backend, Frontend (ExtJS), Templates, Migrationen, Komponenten
Data-Dir Config::get('datadir') Anhänge, Briefvorlagen, Rechnungen, Import-Inbox, Hilfetexte, FOP-/phpdocx-Konfiguration, kundenspezifische Schriften, Hilfsthemen
Datenbank PostgreSQL-DB (biso) Sämtliche Geschäftsdaten (Beratungsfälle, Personen, Termine, Berichte, Parametrierung, Logs etc.)

Alle drei Bereiche zusammen ergeben eine vollständige, wiederherstellbare BISO-Instanz.

Was muss gesichert werden?

Backup

Voraussetzungen

1. Webroot-Backup (Applikation)

Das Webroot enthält den ausführbaren Anwendungscode inkl. aller Komponenten (Gaia, phpdocx, FOP) und Konfigurationen. Es ändert sich nur bei Updates — entsprechend ist die Sicherungsfrequenz hier typischerweise niedriger als beim Data-Dir oder der DB.

Auszuschliessen sind kundenspezifische Konfigurationsdateien (siehe oben).

rsync -a \
    --exclude='data' \
    /PATH/TO/WEBROOT/ \
    /var/backups/biso/webroot/

Hinweis: Die ausgeschlossenen Pfade entsprechen exakt dem rsync-Pattern aus der Update-Anleitung (siehe Installation), damit der Stand eines Backups jederzeit mit dem eines Updates vergleichbar ist.

2. Data-Dir-Backup (Nutzdaten)

Das datadir (siehe Config::set('datadir', ...) in config.php) enthält alle benutzergenerierten Dateien. Bei produktiven Installationen wächst dieser Bereich kontinuierlich und muss entsprechend häufig gesichert werden.

Nicht zu sichern sind:

# Ermittlung / Setzen des datadir:
DATADIR=/var/www/biso-webroot/data

rsync -a \
    --exclude='tmp/' \
    --exclude='*.log' \
    --exclude='maintenance.on' \
    "$DATADIR/" \
    /var/backups/biso/data/

3. Datenbank-Dump (Plain SQL)

Der Datenbank-Dump wird als Plain-SQL (gemäss Vorgabe) erstellt. Damit ist er ohne zusätzliche Werkzeuge inspizier- und versionierbar.

# Konfiguration der Datenbank-Parameter, siehe config.php, Config::set('gaia.db',[ ....]))
DB_HOST=db.host
DB_NAME=biso_db
DB_USER=biso_user

pg_dump \
    -h "$DB_HOST" \
    -U "$DB_USER" \
    -d "$DB_NAME" \
    --no-owner \
    --no-privileges \
    --clean \
    --if-exists \
    | gzip > /var/backups/biso/db/biso_$(date +%Y%m%d_%H%M%S).sql.gz

Hinweis: Falls zusätzlich die optionale Log-Datenbank biso_log betrieben wird (siehe Konfiguration), muss diese separat gesichert werden.

Empfohlenes Vorgehen

Die drei Backup-Schritte werden idealerweise konsistent nacheinander ausgeführt. Bei produktiven Systemen empfiehlt sich:

  1. Webserver-/PHP-Worker kurzzeitig stoppen oder BISO in den Wartungsmodus schalten (php biso-cli maintenance on), damit keine Schreibvorgänge während des Backups stattfinden.
  2. DB-Dump erstellen.
  3. Data-Dir sichern.
  4. Webroot sichern.
  5. Wartungsmodus wieder deaktivieren (php biso-cli maintenance off).

Restore (Disaster Recovery)

Voraussetzungen

Reihenfolge

1. Webroot wiederherstellen
2. config.php bereitstellen
3. Data-Dir wiederherstellen
4. Datenbank wiederherstellen
5. Konfiguration & Migrationen
6. Verifikation

Die Reihenfolge ist wichtig: Ohne Webroot-Code kann die BISO-Anwendung die DB nicht interpretieren. Ohne config.php weiss die Anwendung nicht, wo Data-Dir und DB liegen. Ohne DB-Schema scheitert jeder Request.

1. Webroot wiederherstellen

Das Webroot wird aus dem Backup an die vorgesehene Stelle zurückgespielt:

rsync -a /var/backups/biso/webroot/ /PATH/TO/WEBROOT/

2. Data-Dir wiederherstellen

Aus dem Data-Dir-Backup an den in config.php konfigurierten Pfad (Config::set('datadir', ...)) zurückspielen. Pfad-Berechtigungen prüfen (siehe Installation):

rsync -a /var/backups/biso/data/ "$DATADIR/"
chown -R www-data:www-data "$DATADIR"
chmod -R u+rwX "$DATADIR"

3. Datenbank wiederherstellen

Ziel-Datenbank vorbereiten (sofern nicht bereits vorhanden) und Dump einspielen:

# auf dem DB-Server oder einem Client mit installiertem psql:
# Datenbank vorbereiten (ev. alte löschen):
psql -U biso -d postgres -c "DROP DATABASE biso;"
psql -U biso -d postgres -c "CREATE DATABASE biso OWNER biso ENCODING 'UTF8' LC_COLLATE='de_CH.utf8' LC_CTYPE='de_CH.utf8';"

# Restore ausführen
gunzip -c /var/backups/biso/db/biso_YYYYMMDD_HHMMSS.sql.gz | psql -U biso -d biso

4. Konfiguration und Migrations

  1. config.php aus dem Backup an den richtigen Pfad kopieren, falls nicht im Webroot-Backup

  2. Prüfen, dass Config::set('env', 'PROD') und die DB-Connection-Daten stimmen.

  3. Offene DB-Migrationen ausführen, damit das DB-Schema mit dem Anwendungscode übereinstimmt:

    cd /PATH/TO/WEBROOT
php biso-cli migration exec

    Bei Docker-Setups:

    docker compose exec web83 php biso-cli migration exec

  4. Crunz-Scheduler-Cronjob und Queue-Runner sind eingerichtet (siehe Konfiguration).

  5. PHP-Worker/Webserver neu starten.

Verifikation

Daten-Refresh (Produktion → Test)

Ziel

Der Test-Stand soll einen möglichst realitätsnahen Datenbestand enthalten, damit Tests, Bug-Reproduktionen und Schulungen mit produktionsähnlichen Daten möglich sind. Dies ist kein Disaster-Recovery — der Produktionsstand bleibt unangetastet.

Voraussetzungen

Ablauf

# 1. Test-System in Wartungsmodus
php biso-cli maintenance on

# 2. Test-Webserver / PHP-Worker stoppen
# Je nach System, hier am Beispiel Debian mit apache und fpm:
systemctl stop apache2 php-fpm

# 3. Frischen Prod-DB-Dump holen (oder bereits erstellen)
rsync -a prod:/var/backups/biso/db/biso_latest.sql.gz /tmp/

# 4. Test-DB leeren und neu aufsetzen
docker compose exec db psql -U biso -d postgres \
    -c "DROP DATABASE biso_test;"
docker compose exec db psql -U biso -d postgres \
    -c "CREATE DATABASE biso_test OWNER biso ENCODING 'UTF8' LC_COLLATE='de_CH.utf8' LC_CTYPE='de_CH.utf8';"
gunzip -c /tmp/biso_latest.sql.gz | docker compose exec -T db psql -U biso -d biso_test

# 5. Test-Data-Dir leeren und mit Prod-Stand füllen
rm -rf "$TEST_DATADIR"/
rsync -a prod:/var/backups/biso/data/ "$TEST_DATADIR/"

# 6. Test-DB-Migrationen ausführen
php biso-cli migration exec

# 7. Test-Worker wieder starten
systemctl start apache2 php-fpm

# 8. Wartungsmodus entfernen
php biso-cli maintenance off

Hinweis zu Kunden-Parametern: Die params-Tabelle enthält kundenspezifische Einstellungen (inkl. kunde-Spalte). In der Regel sollen diese für die Test-Instanz übernommen werden — andernfalls müssen sie nach dem Restore manuell angepasst werden (vgl. Installation).

Hinweis zu Session-/Login-Daten: Sessions gehören nicht in den Prod-Dump — der Refresh übernimmt sie zwar formal, sie sind aber nach dem DB-Restore hinfällig. Benutzer müssen sich auf der Test-Instanz neu einloggen.

Anonymisierung (optional, empfohlen)

Personenbezogene Daten (Klientendaten, Berater-Notizen, Beratungsfälle, Anhänge) werden beim Refresh nicht automatisch unkenntlich gemacht. Vor einem Test-Stand, auf den externe Personen (z.B. Entwickler, Schulungsteilnehmer, Supporter) Zugriff haben, muss anonymisiert werden.

Vorgehen gemäss Anonymisierung:

# In config.php des Test-Systems sicherstellen:
#   Config::set('env', 'dev');

php biso-cli anonymizer anonymize --do-it

Wichtig: Der Anonymizer ist aus Sicherheitsgründen nur in env = dev aktiv und darf niemals auf einem Produktionssystem ausgeführt werden.

Anonymisiert werden u.a. die Tabellen person, beratungsfall, bf_termin, bf_termin_protokoll, bf_notiz, bf_log. Dateien im Data-Dir werden nicht anonymisiert — beim Refresh bewusst mit-übernommene Anhänge in $TEST_DATADIR/attachments/ enthalten weiterhin die Originaldateien. Bei strengen Datenschutzanforderungen ist das Data-Dir-Restore entsprechend einzuschränken oder die Anhänge sind vorgängig gesondert zu bereinigen.

Aufräumen

Nach erfolgreichem Refresh: