Discourse Backup Vs DO Backup?


(Siraj Mahmood) #1

I have slightly confusion, if discourse have fully backup option so do we need to enable DO backup option which is premium at this time. Is discourse backup contains all things of discourse community forum.
Actually DO backup is premium and friendly speaking still I have zero experience with DO backups.

Secondly, DO snapshots are free, is it good and is it contains all things of discourse forum?

I need suggestion from any experts who can understand this strategy. Thank you!


(Alan Tan) #2

Discourse backups are stored locally on to the same DO droplet which means that if you lose data on the DO droplet for whatever reason, the backups are lost too.

Difference between a DO Snapshot and Weekly Backup?

DigitalOcean users have the option of backup and snapshot features. The main difference between the two is that snapshots can be generated manually and can be enabled at any time, while backups are run automatically weekly, and must be enabled during the droplet’s creation. Additionally, the server shuts down during snapshots, but stays powered on during backups, which happen in the background.

If you want to play it safe and not rely on the weekly snapshots, you could enable the option to upload the backups to an Amazon S3 bucket and at a much higher frequency. Search for “backup” in your admin site settings. :smile:


#3

Digital Ocean backups take a backup of the whole VM’s disk. If you rely on this 9 times out of 10 I bet when you try and restore you’ll have a corrupt database.

Discourse backups take into account all the files uploaded and the database, everything else (the software that runs discourse for example) can really just be setup again easily assuming you’re installing via docker and remember your container configurations.

I recommend just setting up discourse to backup to S3 and save some locally as you get the best of both worlds this way. You could also use a combination of DO backups and Discourse backups by relying on DO to backup the files you have on disk (there by saving the backups discourse takes and saves in the backup folder) and just restore those backup files.

Hopefully this makes sense.


(Alan Tan) #4

Why would you end up with a corrupted DB? :thought_balloon: If the files on disk works for the application at the point of the backup/snapshot, shouldn’t it work when you restore it to the same state?


#5

Not quite, just because they’re on the disk doesn’t mean they’re up-to-date or in sync (although chances are they are). The PostgreSQL docs themselves say that with regards to file system level backups:

The database server must be shut down in order to get a usable backup.

Not to mention that PostgreSQL may have data within its internal buffer that hasn’t been written to disk yet.

You have to understand that a database isn’t just a file sitting on the disk that the DBMS understands and lets you query, its lots of smaller files separated into directories and multiple files.

If you’re super, super keen on going the DO backup route and not using Discourse’s backup system then I suggest having a look at Barman which with some configuration should be able to take snapshots of your DB and write them to disk by using WAL archives. Checkout this answer on Stack Overflow for more info.


(Alan Tan) #6

Thanks for explaining. :+1:

Just to confirm a few ideas:

  1. If I take a snapshot which requires me to spin down Discourse, I should be able to restore my application in the same state without any risk of corrupted data.

  2. If a user decides not to upload Discourse backups to S3, he can still depend on the local Discourse backups by backing up the DO droplets. The downside for this is that there doesn’t seem to be a defined frequency in which DO backups are run.


#7

Correct, since you’re required to shutdown the droplet (which I hope you’ve done gracefully!) the database should be perfectly fine.

Yep, exactly right. Looking at the docs they’re only taken once a week within an 8 hour window so that’s a lot of data you could lose! I sure wouldn’t want to lose a weeks worth of forum activity. :smile:


(Siraj Mahmood) #8

Actually recently we turned off backup option in DO due to their expensive prices but snapshots are good for beginners. Secondly we are focusing on discourse backup which we are taking daily manually.

Thank you so much for all of the people’s, who give us your precious time :kissing_heart:


(Lars) #9

Also DO backup is like a DOS-attack on your server. Once DO rendered my server completely inaccessible for 4.5 hours. Naturally I disabled DO-backups and implemented an S3-backup thingy…


#10

Is there a correct way to shutdown a server running discourse so that all changes are written to the database ?


(Felix Freiberger) #11

Simply invoking a normal shutdown on the host should correctly halt the container :slight_smile:


#12

The command is

cd /var/discourse/
./launcher stop app


(Anton) #13

Just an update - DigitalOcean introduced live snapshots since then.