Do Supabase backups include Storage files?

No. Supabase database backups do not include the actual files in Supabase Storage. They keep the rows that describe those files. That is easy to miss: after a database restore the catalogue can look fine while every download returns an error.

What survives a Supabase database restore?

The practical test is simple: after recovery, can the application download the expected bytes? A restored storage.objects row proves only that the catalogue entry exists.

Supabase states this directly in its database backups documentation: database backups include Storage metadata but not objects stored through the Storage API. To restore both, keep the PostgreSQL data and object bytes from the same backup window.

Metadata and files are two different assets

Supabase Storage uses database records to describe buckets and objects. Those records contain information such as the bucket, object path and ownership. The content of a PDF, image or video is stored separately. Restoring only the database can recreate the catalogue without recreating what the catalogue points to.

A row count is consequently not a file-integrity check. Ten thousand restored object rows can coexist with zero recoverable files. Verification must fetch the bytes and compare them with evidence captured when the backup was made.

What a useful Storage backup records

• The bucket and full object path, preserving case and special characters.
• The object size and content type.
• A cryptographic checksum, such as SHA-256, calculated from the downloaded bytes.
• The backup timestamp and the database snapshot it belongs to.
• Any version or generation identifier used by the destination object store.

The timestamp relationship matters. If database metadata is captured at 02:00 but file copying continues until 05:00, files may be created, replaced or deleted between those moments. Your recovery report should expose that consistency window instead of presenting both artifacts as one perfectly synchronized snapshot.

Ways to copy Supabase Storage objects

Supabase documents several download paths, including its client libraries, the CLI and the S3-compatible endpoint. The official object download guide is the best starting point because the appropriate method depends on volume and automation requirements.

Small projects

For a small inventory, list objects, download each object and write a manifest containing size and checksum. Retry individual failures, but make the final job fail if any object remains missing. A partially successful copy should never receive a green status.

Larger projects

Use bounded concurrency, resumable transfers where available and an object store in a separate account or provider. Keep deletion rights separate from normal application credentials. A backup that can be deleted by the same compromised credential as production is not an independent recovery layer.

How to test a Storage restore

1. Restore the matching database backup into an isolated Supabase or PostgreSQL recovery environment.
2. Recreate the required buckets and access policies through a documented process.
3. Upload the backed-up objects to the paths referenced by the restored metadata.
4. Compare expected and restored object counts, sizes and checksums.
5. Use the application to download representative private and public objects.

Include edge cases in the sample: a large object, a path containing spaces, a private object, an object owned by a user and a recently replaced file. These checks catch problems that a single public image cannot.

What happens when a Supabase project is deleted?

Supabase describes project deletion as irreversible and says it removes the database, Storage objects, backups, functions and configuration. See the project deletion documentation. If accidental or malicious project deletion is within your threat model, copies must live outside that project lifecycle.

The practical answer

Treat the Postgres dump, Storage-object copy and configuration inventory as separate artifacts joined by one recovery run. Back up each one, retain them independently and prove they work together. That is the difference between restoring a list of filenames and restoring a working product.

For the complete system, read How to Back Up Supabase Properly and use the backup verification workflow to turn each backup into recovery evidence.

How ReviveDB restores Supabase Storage

ReviveDB captures Storage objects outside the Supabase project lifecycle and records bucket, path, size and hash evidence. During a restore to a new project it applies captured bucket configuration, restores the object bytes through the Storage API and then verifies the matching database metadata.

• Storage coverage is recorded per recovery point; unavailable API access is shown instead of silently skipped.
• Object bytes are hash-checked in managed backup storage.
• The target service-role key is supplied only for the restore job, encrypted, expired and wiped afterward.
• A component mismatch fails recovery; secrets and unsupported settings remain explicit actions.

Follow the full restore-to-a-new-Supabase-project guide or review Supabase backup coverage.

Supabase Storage backup questions

Does PITR back up Supabase Storage objects?

No. PITR protects PostgreSQL state, including Storage metadata, but it does not version or replay the separate object bytes.

Can you use storage.objects as a file backup?

No. Those rows are an index of objects, not the object content. Restoring or editing them directly cannot recreate a missing PDF, image or upload.

Can you restore Storage to a new Supabase project?

Yes, if you retained an independent object copy and its manifest. Recreate compatible buckets first, upload objects to the original paths, then compare counts, sizes and hashes before application cutover.

What should a Storage backup manifest contain?

At minimum: bucket, complete object path, byte size, content type, checksum, capture time and the database recovery point it belongs to.