Speicher und Anhänge
PostgreSQL speichert Storage-Objektmetadaten und Anwendungsreferenzen.
Storage dauerhaft betreiben und Anhänge prüfen
PostgreSQL speichert Storage-Objektmetadaten und Anwendungsreferenzen. Das Storage-Backend enthält die Dateibytes. Beide gehören zu derselben Instanz und demselben Sicherungspunkt. Das full-Dateisystemprofil speichert Bytes unter docker/volumes/storage im festgelegten Upstream; S3-kompatibler Storage benötigt einen getrennten Rohdaten-Snapshot. Vergängliche Containerdateien sind kein dauerhafter Storage. Überwachen Sie Kapazität für Datenbank, Anhänge und Sicherungen und speichern Sie Backups außerhalb der aktiven Storage-Platte.
Autorisierten Zugriff prüfen
Private Seiten- und Ticketdateien durchlaufen Anwendungsautorisierung vor erlaubtem Download. Eine veröffentlichte Seite stellt nur Dateien ihres veröffentlichten Satzes über signierte URLs bereit. Sie öffnet weder den privaten Bucket noch die authentifizierte Route. Eine vorhandene Datei beweist nicht korrekte Metadaten, Richtlinien, Schlüssel oder Berechtigungen. Laden Sie mit einem Demokonto eine Datei hoch und herunter und vergleichen Sie SHA-256. Wiederholen Sie dies nach Wiederherstellung für jeden verwendeten Bucket.
Fehler beheben
Führen Sie die Supabase-Prüfung aus, prüfen Sie richtigen Stack und Service-Role-Konfiguration und vergleichen Sie Objektdatensätze, Rohbytes und erhaltene Schlüssel. Beheben Sie Dienst-, Richtlinien- oder Konfigurationsfehler vor Wiederholung. Löschen Sie niemals einen nicht leeren avatars-Bucket wegen einer Warnung. SQL-Datensätze allein stellen keine Bytes wieder her. Stellen Sie bei S3 den Rohbackend-Snapshot wieder her, nicht über /storage/v1/s3, das widersprüchliche Metadaten erzeugen kann.
pnpm verify:supabase --db-url "$SUPABASE_DB_URL" \
--supabase-url "$MINDDY_PUBLIC_SUPABASE_URL" \
--service-role-key "$SUPABASE_SERVICE_ROLE_KEY"
Dateisystem-Storage unter Docker Desktop
Im getesteten macOS-Profil mit Docker Desktop lieferte ein Host-Bind-Mount ENOTSUP, als Storage erweiterte Attribute schrieb. Ein neues benanntes Linux-Volume verhinderte diesen Fehler. Bei einer neuen Installation ohne Objektbytes ersetzt der folgende dauerhafte Override nur den Storage-Mount. Behalten Sie RESTORE_OVERRIDE im installierten Compose-Kontext bei. Ersetzen Sie keinen bereits befüllten Mount durch ein leeres Volume und überschreiben Sie keinen vorhandenen Restore-Override: Stoppen Sie Schreibzugriffe und sichern Sie zuerst die Bytes mit den Sicherungs- und Wiederherstellungsverfahren.
: "${RESTORE_OVERRIDE:=/etc/minddy/storage-volume.yml}"
export RESTORE_OVERRIDE
test ! -e "$RESTORE_OVERRIDE"
export STORAGE_VOLUME=minddy-filesystem-storage
if docker volume inspect "$STORAGE_VOLUME" >/dev/null 2>&1; then
echo "Refusing to replace an existing Storage volume." >&2
exit 1
fi
cat > "$RESTORE_OVERRIDE" <<EOF
services:
storage:
volumes:
- $STORAGE_VOLUME:/var/lib/storage
volumes:
$STORAGE_VOLUME:
EOF
# Apply this overlay with the installed Compose context before the first start.