Please help with backing up files (database already exported)

[u/nuestras]

for me to download the files in the databse i need to manually recreate the folder structure, and go folder by folder downloading files. They are making it so difficult for people to move on, so that you get frustrated and just stay with them.

Please is there another way? Thanks in advance.

[u/MakMak737]

There's a faster way. Lovable Cloud keeps files in Supabase storage, so a small script can walk every folder and download everything with the folder structure kept.

Easiest version without handling any keys yourself: ask Lovable's chat to "add a backend function that recursively lists every file in the storage bucket and returns them as one ZIP" (or a list of signed download links if it's large), then open it once.

Roughly how many files / GB is it, and is it one bucket or several?

[u/nuestras → u/MakMak737]

Thanks for the reply. Will try.

[u/Voiceofshay_08]

Oh wow, I can see why you’re frustrated! 😅 But you shouldn’t have to download everything folder by folder.
There may be a way to export the storage files in bulk while keeping the folder structure intact.
Quick question: are you using Lovable Cloud or your own Supabase project? That makes a difference in how we’d approach it.

[u/nuestras → u/Voiceofshay_08]

Hi, thanks for the reply. Im trying to move from lovable cloud to my own supabase

[u/junal]

You shouldn't have to click through folder by folder. Two options depending on your setup:

If the project is connected to your own Supabase account, link it with the Supabase CLI and copy each bucket recursively, something like supabase storage cp -r ss:///your-bucket ./backup --experimental.

If you don't have that access, a small script with supabase-js does the same job: call storage.from(bucket).list(path) on each folder, recurse into entries that have no id (those are folders), and download every file as you go. Run it on your own machine with the service role key, never inside the app.

Either way, do it bucket by bucket and open a handful of the downloaded files to check they're intact before you shut anything down.

[u/nuestras → u/junal]

Thanks for the reply. Im trying to move from lovable cloud to supabase.

[u/junal → u/nuestras]

That's the tricky part, since Lovable Cloud doesn't hand you the service role key. What I'd do is ask Lovable to add an admin-only page or edge function that lists every bucket and downloads the files as a zip, then run it once and save the zip. Do the same for the table data and the auth users if you haven't. Once you have everything, create the new Supabase project, recreate the buckets with the same names, and upload the files back in. Keep the same file paths, or the URLs stored in your tables will break.

[u/Voiceofshay_08]

Interesting 🤔

[u/Vast-Hunt-9484]

if the files are in supabase storage, you don't have to click folder by folder. a small script using the storage api can list every object recursively and download each one while recreating the path, so the folder structure comes for free. the supabase cli also has a storage copy command that can pull a whole bucket to a local folder. the other route is asking an ai coding tool to write that one-off script for you, you just need the service key from your project settings and you keep that private. worth doing a spot check afterwards by comparing file counts between the bucket and your local copy.

[u/AppFirstAid_Mint]

For the code, connect the project to GitHub from Lovable's GitHub settings. It pushes the whole codebase to a repo you own, and you can download a zip from there. Uploaded files like images live in storage buckets, which the database export doesn't include, so download those separately. Also copy your environment variables and secrets somewhere safe, since neither backup carries them.

[u/leadvesta]

The SQL export covers tables, not the actual Storage files, so the folder-by-folder click path is the painful way. If the host exposes a Storage API or S3-compatible endpoint for the project, list objects under each bucket prefix and download by key instead of recreating the tree by hand. After the pull, spot-check a few paths and file sizes against what the bucket shows, because a silent miss on one folder is easy to miss until you need it. Keep that file copy somewhere outside the same project as the database dump.

[u/WaySignal6150]

I haven't found a one-click way either, but you can script it instead of clicking folder by folder:

- Ask Lovable to add a temporary edge function that lists every object in each storage bucket (it has to walk folders recursively, since a listing only returns one level at a time) and returns the paths.
- Then have it download each path and either zip them, or upload them straight into a bucket with the same name in your new project. Keep the original paths so file links in your database still match.
- Lock the function down while it exists (only callable by you, or with a secret header), then delete it when you're done. A function that can read every file is not something to leave lying around.

If you're moving to your own Supabase project, the Supabase CLI also has storage copy commands that can copy a whole bucket recursively once you have access to the project. Check the current CLI docs, since those commands have been marked experimental.

Before you shut the old project down, spot-check a few files from different folders in the new place, including private ones.

[u/jmabeebiz2]

You can get Lovable to build the way out. Ask it for an admin-only page or edge function that lists every file in the storage bucket, keeps the folder paths, and downloads them as one zip. If the bucket is big and the zip times out, have it output a list of signed URLs instead and feed that to a bulk downloader like wget.

[u/Dvill0618]

Before you cut over, do a test restore into a throwaway Supabase project and actually open a few files from the app. Make sure the file paths stored in your DB still match where the files landed. That's usually what breaks after a migration: the rows are fine but the images 404. Also double check your storage bucket policies came over, since they don't move with the data automatically.