Isn’t just 1 backup a day too risky? If something happens to the server and the last backup happened yesterday, what do I do? Users registered between yesterday and today, are they no longer registered? I think it is better to make backups more frequent, perhaps every hour. But in case, you have to put the site in read-only before making a backup? Thanks in advance!
3 Likes
+1 for this, again. Discourse is the only dynamic system where one can automatize backup of database only once a day.
I don’t expect this to change in core anytime soon. The I have had conversations about changing the default to more than once a week and that’s not happening.
I think what might be good is a plugin that would add a site setting to make database-only backups in some number of hours (there is no reason to keep a zillion copies of uncompressable uploads in all of those full backups). If you’re interested, PM me or ask in marketplace.
1 Like
If you need a better disaster recovery, I recommend following Running Discourse with a separate PostgreSQL server and running PostgreSQL on your own where you can control the exact high availability you need, like live sync replicas, point-in-time recovery and more frequent backups.
3 Likes
May I ask reason for this policy, is it techinal or more class wanting? 24 hours gap between backups is quite critical issue on high traffic forums. Or is this something you offer only to paying customers?
1 Like
Does running Discourse with a separate PostgreSQL server reduce speed by being on a different server?
1 Like
Sure, that is one solution. Quite rare solution among apps, though. In PHP/MySQL-world backuping database using cron would be really easy to do, but again - in that world every app can do it by themselves, with or without some plugin.
Yes, I’m a little bit more than just average end user 
but I have very thin understanding how docker, rails etc. is working and for me situation where common tasks are almost mission impossible is really hard to understand. Sure, perhaps it is because of my limitations, but I’m not the only one wondering this, though.
Well. We don’t get database backups easily in the near or medium future, I got that.
1 Like
You can setup PostgreSQL backups with cron too. Nothing different here.
Not in any relevant way. Every Discourse instance we host, like this one here, uses a database in a dedicated server.
2 Likes
I only ask you two questions to understand better.
- The database is the only thing you need to restore everything right? The backup that is done daily through the settings, does the backup only of the database?
- Should the forum be in read-only mode when making the backup to the database? Or can it be done without any problem, at any time?
Really thanks in advance!
2 Likes
Settings live in the database.
Technically you also want to backup the uploads folder and the app.yml site definition. However that is usually dealt with by having the app.yml in source control and the uploads in a object storage service.
No need for read-only.
4 Likes
So assuming I have the database on a separate server and do backups to that database every hour. If I also backup, from the settings in the admin panel, only the files including the app.yml file and the uploads folder would be included in the backup, but not the database right? @Falco
1 Like
The backup will include the database and the uploads (if they are not on S3). app.yml is not in the backup, as Discourse cannot read it.
What I recommend for most people is having the backups on S3 and app.yml somewhere that you can get it if there is an emergency. Then you can build a new container with the app.yml and restore it from the command line. But if you have the technical chops to backup/restore postgres with some other tool, and images on on S3 (or maybe you have them backed up some other way too), then you can just rebuild the container and you’re back up.
Or maybe you want to have multiple continually mirrored postgres servers and then arrange to automatically switch to the backup if the primary goes down.
There are a zillion ways to provide more frequent backups than Discourse provides. If you need more frequent backups, then you’ll need to do them some other way.
2 Likes
One other point here is risk and maintenance: if you use the out of the box daily solution it is likely to be more robust and reliable as a back-up solution that if you go ahead and configure your own. What if something goes wrong with your own solution and you find out only when it’s too late? At least with the standard solution you have 100’s of sites testing it daily.
Given I’ve not had a single experience of corruption across several sites in 4 years the risk of actually needing the back-up in the first place is also low …
Perhaps others can mention bigger risks, but probably the biggest risk is problems due to filling up the server? So keep an eye on space? Set up an alert?
3 Likes
So, from what I understand the best way is to keep everything separately.
Main server for running Discourse. Then a server for PostgreSQL and S3 (or any other object storage service) for uploads.
The app.yml file seems to me that it doesn’t change often, so you only need to save it once. Or at most a few times during the month.
This allows you to make backups of your files, even in a more organized way.
If so, I find that their choice not to implement multiple daily backups in the core makes sense. On the other hand, those who have complex needs will certainly make particular configurations like that. And in the end you just need to redo the installation(with the app.yml saved somewhere) and then reconnect it to the database and to the S3 for the data uploads. The backups are in those 2 servers separately, so it’s easy to manage for me. I find it a very fair solution.
Thanks everyone for the explanation.
3 Likes
There’s another thread here: Configure automatic backups for Discourse - #113 by Tris20
@pfaffman made a few recommendations there with links. This lead me the command line as a way of scheduling more frequent backups, which for me is a pretty reasonable solution:
Note that with this solution you could combine it all in a python script to also schedule a copy of the yaml file etc at the same time
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.