Ir al artículo

Almacenamiento y archivos adjuntos

PostgreSQL conserva los metadatos de los objetos Storage y las referencias de la aplicación; el backend Storage conserva sus bytes.

Mantener Storage duradero y diagnosticar archivos adjuntos

PostgreSQL conserva los metadatos de los objetos Storage y las referencias de la aplicación; el backend Storage conserva sus bytes. Ambos deben pertenecer a la misma instancia y al mismo punto de copia. El perfil full con almacenamiento filesystem persiste los bytes en docker/volumes/storage de la distribución upstream fijada. Un backend compatible con S3 necesita un snapshot independiente de los bytes originales. Los archivos efímeros de los contenedores no son Storage duradero. Vigile la capacidad para la base de datos, los adjuntos y las copias, y mantenga estas últimas fuera del disco activo de Storage.

Acceso a archivo autorizado
Metadatos PostgreSQL del objeto
Bytes brutos en archivos o S3
Configuración y claves correspondientes
Una restauración necesita los metadatos, los archivos y la configuración protegida que correspondan al mismo conjunto.

Comprobar acceso autorizado

La aplicación verifica la autorización antes de permitir descargar archivos privados de páginas e incidencias. Publicar una página expone solo los archivos del conjunto publicado mediante URL firmadas; no convierte el bucket en público ni abre las rutas privadas. Que exista un objeto en disco no demuestra que sus metadatos, políticas, clave de cifrado o permisos sean correctos. Con una cuenta de demostración, suba y descargue un archivo y compare su SHA-256. Repita la prueba tras restaurar para cada bucket utilizado.

Recuperarse de un fallo

Ejecute la verificación de Supabase, compruebe que el entorno y la clave service-role corresponden y compare los registros de objetos con los bytes originales y las claves conservadas. Corrija el servicio, la política o la configuración antes de volver a intentarlo. No elimine un bucket avatars que contiene archivos para quitar una advertencia. Restaurar registros SQL no recupera los bytes. Para S3, restaure el snapshot del backend original; no reimporte mediante /storage/v1/s3, que puede crear metadatos en conflicto.

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

Storage con sistema de archivos en Docker Desktop

En el perfil probado de macOS con Docker Desktop, un montaje de directorio del equipo devolvió ENOTSUP cuando Storage escribió atributos extendidos. Un volumen Linux nuevo con nombre evitó el fallo. Para una instalación nueva sin bytes de objetos, el siguiente override persistente sustituye solo el montaje de Storage. Conserve RESTORE_OVERRIDE en el contexto instalado de Compose. No sustituya un montaje con datos por un volumen vacío ni sobrescriba un override de restauración existente: detenga las escrituras y preserve primero sus bytes mediante los procedimientos de copia de seguridad y restauración.

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.

Artículos relacionados