Stockage et pièces jointes

PostgreSQL conserve les métadonnées des objets Storage et les références applicatives.

Conserver Storage durable et diagnostiquer les pièces jointes

PostgreSQL conserve les métadonnées des objets Storage et les références applicatives. Le backend Storage conserve les octets. Les deux appartiennent à la même instance et au même point de sauvegarde. Le profil full sur fichiers persiste les octets dans docker/volumes/storage du Supabase amont épinglé ; un backend S3 compatible exige un snapshot brut distinct. Les fichiers éphémères des conteneurs ne sont pas durables. Surveillez la capacité de la base, des pièces jointes et des sauvegardes, en gardant celles-ci hors du disque Storage actif.

Accès fichier autorisé par l’application

Métadonnées d’objets PostgreSQL

Octets bruts sur fichiers ou S3

Configuration et clés correspondantes

Restaurer un fichier exige de réunir son enregistrement en base, ses octets stockés et les clés correspondantes.

Vérifier les accès autorisés

Les fichiers privés de pages et tickets passent par l’autorisation applicative avant qu’un téléchargement soit généré. Publier une page expose uniquement les fichiers de l’ensemble publié au moyen d’URLs signées ; cela ne rend pas le bucket public ni la route privée anonyme. Un objet présent sur disque ne prouve pas que métadonnées, politiques, clé et permissions sont correctes. Avec un compte de démonstration, téléversez puis téléchargez un fichier et comparez son SHA-256. Recommencez après restauration dans chaque bucket utilisé.

Résoudre une panne de fichier

Lancez le vérificateur Supabase, vérifiez pile et clé service-role, puis comparez enregistrements des objets, octets du backend et clés conservées. Corrigez la panne de service, politique ou configuration avant de réessayer. Ne supprimez jamais un bucket avatars non vide pour éliminer un avertissement. Restaurer les enregistrements SQL seuls ne restaure pas les octets. Pour S3, restaurez le snapshot brut du backend, sans passer par /storage/v1/s3 qui peut produire des métadonnées contradictoires.

Bash

pnpm verify:supabase --db-url "$SUPABASE_DB_URL" \
  --supabase-url "$MINDDY_PUBLIC_SUPABASE_URL" \
  --service-role-key "$SUPABASE_SERVICE_ROLE_KEY"

Stockage filesystem avec Docker Desktop

Sur le profil macOS Docker Desktop testé, un montage de dossier hôte a renvoyé ENOTSUP lors de l’écriture des attributs étendus par Storage. Un nouveau volume Linux nommé a évité cet échec. Pour une nouvelle installation sans octets d’objets, l’override persistant suivant remplace uniquement le montage Storage. Conservez RESTORE_OVERRIDE dans le contexte Compose installé. Ne remplacez pas un montage déjà rempli par un volume vide et n’écrasez pas un override de restauration existant : arrêtez les écritures et préservez d’abord ses octets avec les procédures de sauvegarde et de restauration.

Bash

: "${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.

Articles associés

Sauvegardes et restauration