The best idea I have is to design your App in a way so that you can create the functionality yourself. A good pattern to use with Files & Images in Bubble is to have a table that stores your uploaded file metadata. Then with this table, you have the information, in particular, the file URL to Bubble S3 storage and Bubble User owner, attached Thing - with that information, you reconstruct your database. Then you could make a script to download it all.
What I am working on with Plan B is one-click database migrations - ie create the schema & copy the data & option sets into an external DB (eg Supabase). This works nicely.
But as you are pointing out - you still have everything in your File storage to worry about. And at the point you are starting to worry about things like “What if I lost some or all my file storage or it got corrupted…” you probably have many Gigs of file store data to recover.
So my thinking for this Plan B is to build into one-click;
is examining the Bubble database’s Image and File types,
get the Bubble S3 URL, and grab the bytes and stick it in another s3 storage (Supabase, Xano all have their own S3 buckets).
Then create in a table, the additional metadata of the New Storage URL (see why the file meta table above was a good idea) - so you have all the information to reconstruct your database. (old Bubble storage URL, and new storage URL) with a little bit of SQL.
I think this is possible and completes the circle of getting ALL your data backed up in a useful way.
The reason I mention it in so much detail is that maybe some smart folks reading this will think … - “Actually Lindsay there is a much easier way - why don’t you just …” and save me a few days tinkering