Einrichtung

2 von 6 Schritten erledigt, 4 Pflichtschritt(e) offen.

✓

Ablage dauerhaft machenErledigt

Die Sicherungen liegen unter /app/src/tiles-backup und überleben einen Container-Neubau.

automatisch gewählt: Volume /app/src

Datenbanken erreichbarOffen

Der Agent hat in der Umgebung keinen Postgres-Zugang gefunden. Er sucht nach Verbindungsangaben in beliebigen Variablen (DATABASE_URL, POSTGRES_HOST + POSTGRES_USER + POSTGRES_PASSWORD, PGHOST, …) und findet den Server bei fehlender Hostangabe auch selbst im Docker-Netz. Liegt keine solche Variable vor, ist eine ausdrückliche Angabe nötig — siehe unten.

1 Projekt-ENV-Datei(en) in / gelesen
In der Umgebung wurde kein Postgres-Zugang gefunden

Zwei Geheimnisse setzenOffen

Das sind die einzigen Angaben, die der Agent nicht selbst ermitteln kann — Geheimnisse lassen sich nicht erraten. In der Projektverwaltung eintragen; hier lassen sich ENV-Variablen nicht setzen. Die Werte unten sind frisch gezogene Zufallswerte, sie werden nirgends gespeichert.

ENV-Variablen

BACKUP_RESTIC_PASSWORD=n-GpUhGIyLgf4hK2SDp6bmKckmn-4bfnuGgVZ2Niqok
BACKUP_UI_PASSWORD=PxHuLhwo_GtimnZ-

# Nur nötig, weil in der Umgebung kein Postgres-Zugang gefunden wurde:
BACKUP_PG_DISCOVER_URL=postgres://<benutzer>:<passwort>@<db-container>:5432/postgres

# Nur für den strengen Betrieb — ohne Token wird ebenfalls gemeldet, die
# Meldung gilt der Agenturplattform dann aber als ungeprüft. Einmal in der
# Projektverwaltung als gemeinsame Variable (Wildcard) genügt für alle Server:
BACKUP_STATUS_TOKEN=<token der agenturplattform>

BACKUP_RESTIC_PASSWORD zusätzlich in den Passwort-Manager der Agentur — Schlüsselverlust macht das Backup wertlos.

✓

Meldung an die AgenturplattformErledigt — ungeprüft

Nach jedem Lauf geht ein Statusbericht an https://agenturverwaltung.tiles.at/api/backup-status. Hier ist nichts einzutragen: Das Ziel steht fest im Agenten, der Servername wird aus PRODUCTION_URL abgeleitet. Ohne Token werden die Meldungen dort als ungeprüft gekennzeichnet: Die Ampel ist ein Hinweis, kein Beweis, denn wer die URL kennt, könnte ein Backup melden, das es nie gab. Für den strengen Betrieb BACKUP_STATUS_TOKEN in der Projektverwaltung einmal als gemeinsame Variable (Wildcard) anlegen — danach findet jede Kopie des Agenten es von selbst, auch auf Servern, die es heute noch nicht gibt. Unabhängig davon lässt sich der Zustand über GET /api/health mit einem beliebigen Uptime-Wächter prüfen: Antwort 200 heißt Backup aktuell, 503 heißt überfällig.

Erstes Backup und Restore-TestOffen

Auf der Übersicht auf „Backup jetzt starten" — nicht auf die Nacht warten. Danach den Restore-Test einmal laufen lassen (siehe docs/RESTORE.md).

Selbst ermittelt — hier ist nichts einzustellen

Diese Werte liest der Agent aus der Umgebung. Eine ENV-Variable braucht es nur, wenn etwas davon überschrieben werden soll.

Servername: srv1870022 (abgeleitet aus tiles-backup.srv1870022.hstgr.cloud)
Ablageverzeichnis: /app/src/tiles-backup
automatisch gewählt: Volume /app/src
Erkannte Volumes: /app/public, /app/src, /app/.next
Datenbankzugang: 1 Projekt-ENV-Datei(en) in / gelesen
In der Umgebung wurde kein Postgres-Zugang gefunden
Zeitplan: täglich um 02:30 (Europe/Vienna)

Was danach von allein läuft

Sicherung: täglich um 02:30 (Europe/Vienna), ohne Zutun
Neue Datenbanken: müssen in BACKUP_PG_URLS ergänzt werden — mit BACKUP_PG_DISCOVER_URL entfällt das
Aufräumen: 7 täglich / 4 wöchentlich / 6 monatlich — ältere Sicherungen werden am Ende jedes Laufs entfernt
Verpasste Läufe: werden nachgeholt, wenn das letzte Backup älter als 26 Stunden ist
Restore-Tests: nur einmalig im Pilot — bewusst keine turnusmäßigen Tests und keine laufende Protokollierung