# Update & Backup

## Backup

```bash
bash scripts/backup.sh
```

Das Skript erstellt einen Dump der Datenbank sowie ein Archiv der Uploads im Verzeichnis `backups/`. Die Rotation erfolgt nach folgendem Schema:

- 7 Tages-Backups
- 4 Wochen-Backups
- 12 Monats-Backups

Ein `flock`-Lock verhindert parallele Läufe bei Verzögerungen.

### Manuelles Backup

```bash
docker compose exec db mariadb-dump -u steuerkram -psteuerkram steuerkram \
  > ~/steuerkram_backup_$(date +%Y%m%d_%H%M).sql
```

---

## Datenpersistenz

| Pfad | Inhalt |
|---|---|
| `./data/mariadb/` | MariaDB-Datenbankdateien |
| `./data/belege/` | Hochgeladene Belege |
| `./data/logo/` | Firmenlogo |

Alle drei Pfade liegen außerhalb des Containers und bleiben bei `docker compose down`
erhalten. Details in [`data/README.md`](../data/README.md).

Ein vollständiges Backup umfasst **Datenbank und Dateien gemeinsam** – ohne
`data/belege` verweisen die Beleg-Datensätze der Datenbank ins Leere. `scripts/backup.sh`
sichert beides und warnt, wenn das Datei-Archiv leer bleibt.

> **Alte Datei-Backups:** Archive aus der Zeit vor dem Umzug enthalten ein
> `uploads/`-Verzeichnis. `scripts/restore.sh` erkennt dieses Format und verteilt den
> Inhalt automatisch auf `data/belege` und `data/logo` – solche Backups bleiben also
> einspielbar.

---

## Update

Für ein vollständiges Update steht `scripts/update.sh` bereit. Es führt alle notwendigen Schritte automatisch aus.

```bash
./scripts/update.sh
```

Das Script erledigt in dieser Reihenfolge:

1. **Voraussetzungen** – Docker, Docker Compose und Git werden geprüft
2. **Backup** – `scripts/backup.sh` wird vor jeder Änderung aufgerufen
3. **git pull** – Code wird aktualisiert; geänderte Dateien werden erkannt
4. **Image-Rebuild** – Das Docker-Image wird neu gebaut, wenn `Dockerfile`, `composer.json`, `composer.lock`, `php/`, `apache/` oder `docker-entrypoint.sh` geändert wurden
5. **Container-Neustart** – `docker compose down --remove-orphans` + `up -d`
6. **Healthcheck** – Wartet bis die Datenbank `healthy` meldet (max. 120 s)
7. **Migrationen** – `scripts/migrate.php` wird explizit ausgeführt (idempotent)
8. **Tests** – Die Test-Suite wird ausgeführt und das Ergebnis angezeigt

### Optionen

| Option | Bedeutung |
|---|---|
| `--no-backup` | Backup überspringen (z. B. wenn gerade erst gesichert) |
| `--no-tests` | Tests nicht ausführen (schnellerer Ablauf) |
| `--force-rebuild` | Docker-Image immer neu bauen, unabhängig von Dateiänderungen |

### Migrationen

Datenbankmigrationen werden von `scripts/migrate.php` verwaltet. Das Script prüft, welche Migrations-Dateien noch nicht angewendet wurden, und führt sie der Reihe nach aus. Es wird sowohl vom Container-Entrypoint als auch von `update.sh` aufgerufen.

```
[migrate] Starte Migrations-Prüfung...
[migrate] Führe aus: NNN_beschreibung.sql
[migrate] N Migration(en) erfolgreich angewendet.
```

Migrationen können auch manuell ausgelöst werden:

```bash
docker compose exec web php scripts/migrate.php
```

### Diagnose bei Fehlern

```bash
docker compose ps          # Container-Status
docker compose logs web    # Web-Container-Log (PHP-Fehler, Migrationen)
docker compose logs db     # Datenbank-Log
```

Falls ein Update fehlschlägt und ein Rollback nötig ist, das letzte Backup einspielen:

```bash
docker compose exec -T db mariadb -u steuerkram -psteuerkram steuerkram \
  < backups/steuerkram_db_YYYYMMDD_HHMM.sql
```