So I’ve been browsing my discourse folders and found a dump.sql file on the /backup folder that I don’t remember creating manually. I’d this a file that is automatically created during backups or am I having an intrusion?
AI-generated summary
Dump.sql file in the backup folder?
The discussion revolves around a dump.sql file found in the /backup folder by Mr.X_Mr.X. Initially, pfaffman and Canapin suspect it might be a remnant of a failed backup. However, gerhard disagrees, stating that the backup process creates a compressed dump.sql.gz file. The uncompressed dump.sql file is more likely to be a result of a restore process or manual intervention.
After Mr.X_Mr.X provides the file path /var/www/discourse/tmp/backups, gerhard concludes that the file was likely manually copied, uploaded, and decompressed at that location. Jagster suggests compression failure as a possibility, but gerhard explains that the pg_dump command with the --compress parameter writes a compressed dump without a temporary file, making it unlikely.
It may have been left behind by a failed backup, perhaps if the disk filled during the backup. It’s not likely due to an intrusion.
I believe I’ve seen this kind of stuff several times and I also thought they were failed backups remnants.
Your explanation seems to confirm this. 
Or not: ↓
There must be a different reason, because the backup process creates a compressed dump.sql.gz file. Only a restore could leave a decompressed dump.sql file, but it should clean up after itself.
@Mr.X_Mr.X What’s the absolute path of the dump.sql file you’ve seen? And what’s the timestamp of the file? Could it be very old?
/var/www/discourse/tmp/backups
There was a dump.sql and a tar.gz typical archive. Nothing else, I’m storing backups on S3.
Unless compression fails?
In case the disk is nearly full, it’s a possibility.
I’m pretty sure the file you are seeing was manually copied/uploaded and decompressed at that location. Backups use /var/www/discourse/tmp/backups/<name>/<timestamp> for storing the temporary dump.sql.gz file und restoring uses a completely different directory.
We are calling pg_dump with the --compress parameter, so it writes a compressed dump without a temporary file. Worst case, you’d see an incomplete dump.sql.gz file.