How to Back Up Supabase Storage Files

Backing up your Supabase database does not automatically protect every file in your project.

Your database backup may preserve information about Storage objects, such as bucket names, file paths, and metadata. However, it does not contain the actual images, PDFs, videos, invoices, or documents stored inside your buckets.

This difference can create a serious recovery gap.

Imagine restoring your database after an accidental deletion. The restored tables may still contain a path such as:

invoices/customer-1024.pdf

But if that PDF was deleted from Supabase Storage, restoring the database will not bring the file back.

A complete Supabase backup strategy should therefore protect two separate parts of your project:

1. Your PostgreSQL database
2. Your Supabase Storage files

This guide explains practical ways to back up Storage files and how to build a simple process that small SaaS teams can maintain.

What Does Supabase Storage Hold?

Supabase Storage is commonly used for files that do not belong directly inside database columns.

Depending on your application, this may include:

• User profile images
• Product photos
• Invoices and receipts
• Customer documents
• Property images
• CSV exports
• Videos
• Application attachments
• Generated reports

The database usually stores information about these files. The actual file data is stored separately as objects inside Storage buckets.

This means a database-only recovery may leave your application partly broken. Records could return, while downloads, thumbnails, avatars, or attachments remain missing.

If you are already protecting your database, How to Back Up Your Supabase Database Automatically explains how SupaBackup stores database backups in your own Google Drive.

Three Ways to Back Up Supabase Storage

The right method depends mainly on the number and size of your files.

Method	Best for	Main limitation
Dashboard download	A few individual files	Too slow for large buckets
Supabase CLI	Developers and repeatable exports	Requires command-line setup
S3-compatible tool	Large buckets and bulk transfers	Requires S3 credentials and secure configuration

Download Files From the Dashboard

The simplest method is downloading files directly from the Supabase Dashboard.

Open the Storage section, select a bucket, browse to the required file, and download it.

This works well when:

• You need only a few important files
• You are checking a single customer attachment
• You want a copy before deleting an object
• Your bucket is very small

It is not a practical full-backup method for a production bucket containing hundreds or thousands of objects.

Manual downloads are also easy to forget, which makes them unsuitable as the main protection method for an active SaaS app.

Use the Supabase CLI

The Supabase CLI includes commands for listing and copying Storage objects.

This is more useful when you want a repeatable process that can download complete folders or buckets to a local machine or backup server.

A typical workflow is:

1. Install and authenticate the Supabase CLI
2. Link the correct Supabase project
3. Create a local folder for the backup
4. Copy the Storage objects
5. Upload the exported files to your chosen backup destination
6. Record the project, bucket, and backup date

The CLI approach is suitable for developers who want control without writing a complete custom application.

However, do not run an untested bulk command against production. Test the process with a small bucket first and confirm that nested folders and file names are preserved.

Use an S3-Compatible Client

Supabase Storage provides an S3-compatible interface. This allows compatible tools to browse and download Storage objects in bulk.

This is often the most practical method for larger projects.

An S3-compatible tool can help you:

• Copy entire buckets
• Preserve folder structures
• Sync files to another storage destination
• Repeat exports with scripts
• Compare source and destination files
• Handle larger numbers of objects efficiently

You enable the S3 connection from the Storage configuration area and generate an access key and secret.

Treat these credentials carefully. They are server-side secrets and should never be exposed in frontend code, public repositories, screenshots, or client-side environment variables.

Where Should You Store the Backup?

Downloading the files is only half of the process. You also need a secure destination.

Possible destinations include:

• Google Drive
• A separate S3-compatible bucket
• A secure backup server
• Encrypted external storage
• Client-controlled cloud storage

For small teams, Google Drive can be convenient because it is familiar and easy to organize. For larger buckets or automated transfers, dedicated object storage may be more practical.

Use a clear folder structure:

Supabase Backups/
└── Project Name/
    ├── Database/
    └── Storage/
        ├── avatars/
        ├── documents/
        └── invoices/

Keep each project and environment separate. Production files should not be mixed with staging files.

Choose a Realistic Backup Schedule

Storage backup frequency should depend on how often files are uploaded or changed.

A small internal tool may need only a weekly export. An active customer portal receiving documents every day may need daily protection.

A practical starting point is:

• Low-activity project: weekly
• Production app with regular uploads: daily
• Important client document system: daily
• High-volume application: scheduled synchronization or a dedicated storage strategy

Ask one question:

How many files could we afford to lose?

If losing one week of uploads would harm users, weekly backups are not enough.

Your database and Storage schedules should also work together. If your database is backed up daily but files are copied only once a month, recovery may produce records that point to missing files.

Protect Private Files During Backup

Storage backups may contain private customer information.

Examples include contracts, invoices, identification documents, internal reports, or confidential attachments.

Use basic security controls:

• Limit access to the backup destination
• Avoid public sharing links
• Keep S3 credentials private
• Do not leave production exports in a Downloads folder
• Remove temporary local copies after use
• Separate client projects
• Review access when a developer or contractor leaves

Public buckets and private buckets may use different access rules in your application, but backup copies should still be treated as sensitive unless you are certain the content is public.

The Database Backup Security Best Practices for SaaS Apps guide provides a broader security process you can apply to both database and file backups.

Test the Storage Restore Process

A folder full of exported files is not enough. You should know how to return those files to Supabase Storage.

Test with a small sample:

1. Create a temporary test bucket
2. Upload several exported files
3. Preserve the original paths
4. Confirm the application can access them
5. Check public or private access rules
6. Verify that database references match the restored paths

Pay special attention to file names, nested folders, content types, and bucket permissions.

For example, restoring an invoice to a different path may still leave the database pointing to the old location. The file exists, but the application cannot find it.

This is why database and Storage restore testing should be done together.

A Practical Supabase Recovery Setup

For a small SaaS product, a realistic setup could be:

• Automatic Supabase database backups to Google Drive with SupaBackup
• Daily or weekly Storage exports based on upload activity
• Separate folders for database and Storage backups
• A fresh export before major migrations or project transfers
• Limited access to production backup files
• A restore test after setup and after major Storage changes

SupaBackup currently protects the Supabase database side of this process. Storage files require their own export or synchronization workflow.

Keeping that distinction clear prevents a false sense of safety.

Final Thoughts

A Supabase project is not fully backed up when only its PostgreSQL database is protected.

If your application uses Storage, you also need copies of the actual objects inside its buckets.

For a few files, the Dashboard may be enough. For repeatable exports, use the Supabase CLI. For larger buckets, an S3-compatible client is usually more practical.

Whichever method you choose, keep the process simple:

Back up the database.
Export the Storage files.
Keep both organized by project and date.
Restrict access.
Test recovery before an emergency.

SupaBackup can handle scheduled Supabase database backups to your own Google Drive. Combine that with a separate Storage backup process to create a more complete recovery plan for your application.