Hello all,
If you are building/maintaining Glide projects for a Client, I’d be curious to understand the backup methods used for apps in production, especially on the data part. Do you automate the process of exporting table data through any means, or do it manually and store it in a cloud storage? Or, taking app backup is the option you follow?
If you can share what has worked, where to be cautious, any best practices that you follow, it’ll be awfully helpful. Thanks !
We usually just duplicate the app periodically, or when we deploy a big feature, but obviously that can’t be automated.
If you want automation, I think the best option is using Make, then query all rows from all relevant tables and export them to CSV files.
Time-based actions might come soon though, and it will change the game.
I think Thinh’s answer is currently the most realistic. I do the same. On occasion, either periodically or prior to major updates, I duplicate the app manually.
Thanks @ThinhDinh and @nathanaelb . Let me follow your footsteps then!
Hi, just found this thread, very good information for a beginner like myself. When you say you “duplicate” the app before doing major updates are you then keeping the data or copying the data?
Could someone explain the workflow a bit more detailed on how you work with apps in production, backups, when releasing new features etc.?
This would be very helpful, thank you!
I duplicate the app/project and select the option where the data is duplicated as well. I don’t feel the need to do a data export on top of that, but that would be even better.
I usually create 3 folders in the team:
I might adapt the names of these folders slightly.
I use emojis and the words “Live” and “Published” because another admin or member of the team might not be familiar with the usual terminology. “Live” is clear in any language and “Published” is the same term used by Glide when publishing an app. In fact the various development environments are somewhat new to me too: Development → Staging → Testing → Production.
In my setup I put Development-Staging-Testing together into “Develop & Test”. And I added another folder for backups. This setup works for me: it’s simple enough and I’ve gotten used to it.
At the end of a session of work usually on an app in the “Develop & Test” folder, I’ll duplicate the app, prepend the date and time to it (2024-10-07 10:00 App Name) and move the duplicate to the backups folder. I then also rename the app in the “Develop & Test” folder with again the current date and time.
If the changes to the app are minor and I know exactly what I’m doing, I might make changes to the (live and published) app in production directly.
When an app in development becomes much more advanced that the (live) app in production and the time has come, I will copy the production URL of the app in production, unpublish the app in production, publish the most advanced app in development and paste the production URL, and move this app in development to the production folder since it is now the published version of the app. In short, this is a URL swap. I have avoided this in past but more recently have been doing this a lot, and it works fine.
Basically for a given project/app, I only ever have one published version in the live in production folder.
The one annoying part with this approach is that if the app in production (live published) was also set up with a domain name, this has to be set up anew.
Curious to hear what others do.
Thank you very much for your detailed explanation. My only question with using this approach would be when duplicating the app and copying the data as well. The Glide docs says:
Copying the data is helpful for:
Creating a backup (or snapshot) of the current app and its data
Creating a new app that is similar to the original but not linked in any way
Wouldn’t that mean that if you spent time on adding new features to an app in your Development folder while the users are using the version in the Production folder, then the data in your Development version would not be up to date when it is time to move it to Production?
Hope my question makes sense 
Yes, if you create a duplicate app as well as duplicate the data…and you make updates to the duplicate…it’s much harder to integrate back into a live environment because the database connected to the duplicate app is not in sync with the live app, and swapping tables is not easy or fun.
If you create a duplicate of the app, but do not duplicate the data, then the database is shared between both apps, and you need to be much more careful. Basic columns and data will still sync between both apps, but computed columns will not. You just need to be careful if you start to mess around with any basic columns in the duplicate app that are used by the live app.
Yes, correct.
If you are doing it that way (which I do), then you need to migrate the production data to the new version of the App when you swap it out. Possible, but extremely fiddly.
Yes very good point. Jeff and Darren have already answered.
I suppose it depends on what type of backup you’re looking for: an absolute backup that has nothing to do with any others versions, or a backup that in a way is backup of an app in staging.
I might start doing both, I like the idea.
EDIT: In the initial phase of development before the app is in production, I think it can make sense to duplicate with separate tables. That’s what I do, because I’m always worried that I’ll break something major and I want to be able to revert back to a clean and stable backup. When the app is in production and being used by users, then I think it makes sense, like Jeff and Daren pointed out, to duplicate with linked tables. The paranoid in me will still do a duplicate with separate tables on top just in case 
Hey, guys.
Just out of curiosity, has any of you experienced any data problem with Glide Tables?
I know it is a high impact risk depending on Glide alone to store our data, because if we do not have an external backup we can lose all our data, but I’m wondering the probability for this risk to occur.
This week I have gotten pretty worried about backups, because my whole company depends on my Glide App, but now I’m a bit relaxed because I saw that almost none of you have external backups. So this may mean that Glide Table is somewhat safe enough.
I would imagine Glide has a pretty robust backup and restore procedure in place for any issues that may occur on their end. Different story if data corruption is self induced by you or your users.
Personally, I’ll go all in on glide tables for small personal projects because data integrity is not critical.
For my main project though, I’ve switched a few small non critical tables to glide tables, but not everything. I still use google sheets and I have an automated google script that runs weekly to archive and back up the data (along with google’s built in up to the minute history log). I have weekly backups going back a few years. If something accidentally gets deleted, it’s really easy for me to restore. I just like having a little more control over my data instead of putting it all in Glide’s hands with no control over backup and restore. Also, it’s just piece of mind that I have a copy of my data and it’s more portable if needed in the future.
The problem is, glide tables perform better than google sheets and don’t incur CRUD updates, so it ends up being a double edge sword in my case.
With that said, I’ve never heard of any major data loss issues on glide’s end. It’s been quite reliable and most people have been using glide data sources for quite a while without issue. The only thing I worry about is data that gets accidentally deleted or changed by you or your users. That stuff is a lot harder to get back.
I think some alternatives are to manually duplicate your project and data periodically. You could also set up workflows that create CSV files that you could download. Neither are great solutions, but options none the less.
Maybe someday I’ll decide to make the jump to all glide tables or be forced into it, but for now I’m more comfortable having some control over my data. I work in IT and where I work it’s pretty trivial to have a “tape” backup restored if needed, along with month end and accounting backups that are readily available at all times for ‘point-in-time’ reference. I think I’m just cognizant of what can go wrong if not prepared, so I like to have stuff backed up.
Awesome!
You made everything so clear for me.
Thanks!
I have a few business apps that are important. I duplicate apps, both with a data sync and non data sync, and this essentially covers the risk of user or developer error.
I have not mitigated the risk of a problem occurring with Glide: Glide shuts down overnight, their servers shut down, their backups don’t work, they push an update to the platform and everything crashes, etc. It always goes really well until one day it doesn’t. I find Glide trustworthy but by definition we don’t know when accidents happen and that’s precisely the point of mitigating risk. I think the only way to mitigate this risk for now is to regularly export app data in settings.
Holy cow!
I didn’t know about the “export app data in settings” function.
You, sir, saved my mind from collapse! Now I can sleep in peace.
Thanks so much.
You’re very welcome 
A Glide app is a table with 4 legs or a car with 4 wheels:
“Export app data in settings” allows you to cover one of those bases: saving the database.
If something were to happen to your application, the other three legs of your table would still need to be rebuilt.
Perfectly put!
With the apps duplicates + database export I think we are safe and sound 