0daf6c393d
Backup-Übersicht/Restore bewusst NICHT als Fake-UI gebaut — im Mock gäbe es keine echten Kundendaten. Stattdessen: - 0004_backups.sql: Register-Tabelle (Metadaten: instance/account, trigger, status, storage_key, size, sha256, Zeitstempel). Dump-Dateien liegen extern. - BACKUP.md: Konzept für Modell A (studio-bezogener Export statt Full-Dump), Erzeugung (pg_dump/cron/Storage/Rotation), Restore-Sicherheitsregeln, geplante API. Bau der Logik, sobald echtes Provisioning steht. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
30 lines
1.4 KiB
SQL
30 lines
1.4 KiB
SQL
-- RAPPORT-HOST — Backup-Register.
|
|
-- Speichert NUR Metadaten zu Backups (eine Zeile pro erstelltem Dump). Die
|
|
-- eigentlichen Dump-Dateien liegen NICHT in dieser DB, sondern am Storage-Ort
|
|
-- (lokale Disk / S3 / Backblaze) — siehe BACKUP.md.
|
|
--
|
|
-- Der Erzeugungs- und Restore-Mechanismus selbst (pg_dump pro Studio gegen den
|
|
-- Rapport-Stack) wird erst gebaut, wenn echtes Provisioning steht. Diese
|
|
-- Tabelle ist die Grundlage, damit die Admin-UI später nur noch lesen/anzeigen
|
|
-- muss.
|
|
|
|
create table if not exists backups (
|
|
id uuid primary key default gen_random_uuid(),
|
|
instance_id uuid references instances(id) on delete set null,
|
|
account_id uuid references accounts(id) on delete set null,
|
|
-- Wofür: automatischer Zeitplan oder manuell vom Admin ausgelöst.
|
|
trigger text not null default 'scheduled', -- scheduled | manual
|
|
status text not null default 'pending', -- pending | ok | failed
|
|
-- Wo die Datei liegt (Pfad/Key am Storage-Ort) + Größe + Prüfsumme.
|
|
storage_key text,
|
|
size_bytes bigint,
|
|
sha256 text,
|
|
error text, -- Fehlertext, falls failed
|
|
created_at timestamptz not null default now(),
|
|
completed_at timestamptz
|
|
);
|
|
|
|
create index if not exists idx_backups_instance on backups(instance_id);
|
|
create index if not exists idx_backups_account on backups(account_id);
|
|
create index if not exists idx_backups_created on backups(created_at desc);
|