Local backups not deleted after they are uploaded to Amazon S3

My backups keep accumulating in /var/discourse/shared/standalone/backups/default even though they are uploaded to Amazon S3.

Here’s my Discourse setup:

Discourse backups:

Backups in the S3 bucket:

And the contents of /var/discourse/shared/standalone/backups/default:

This has been going on for a long time—I have a monthly reminder in my calendar to delete these leftover files. Backup logs are empty: “No logs yet…” and nothing in error logs points to problems with Amazon S3.

Discourse is updated regularly and currently 2.9.0.beta14.

This is a standard install, right? Is there a chance that the OS (or something else) is killing the backup process during the upload? Because even when there’s a backup failure, the local file should be deleted at the end of the process.

1 Like

Yes, standard install on a DigitalOcean droplet, Ubuntu 16.04.7 LTS. Where would the relevant log be?

I used some S3 compatible service for a while that sometimes resulted in backups being left on the local drive, but it was intermittent.

You’d look in /var/discourse/shared/standalone/logs/rails/production.log. It just run a command line backup and see if it has the and behavior.

3 Likes

Production logs only go back a week, so the older “undeleted” backups fall out of that range, but I’ll keep an eye on the future ones. The only backup error entry was this in the 11/30 log:

Started GET "/.env.backup" for 3.236.147.46 at 2022-11-29 19:15:57 +0000
ActionController::RoutingError (No route matches [GET] "/.env.backup")

I see a new undeleted backup in /var/discourse/shared/standalone/backups/default but nothing in the production.log. Nothing in the production_errors.log either. Where else could I look?

P.S. I ran a backup from the CLI and the backup was successfully removed - I’ll try that a few more times to see if I can get an error there.

1 Like

Not having success reproducing the undeleted local backup via CLI, but it does keep happening once or twice a week during the nightly backup. I also don’t see any of the backup log output in production.log. Are you sure that’s where it’s written, @pfaffman ?

I think it should be. When I had a similar problem with some other S3 service, I was unable to find errors in either Discourse or their service. And I gave up and switched to something different. But you’re using AWS, S3, the Real Deal, so I’m quite surprised.

I’ve tried looking like this:
grep -r "Output file is stored on S3" /var/discourse
as that phrase is the last line of the CLI backup output, but nothing is found.

Any chance that the server reboots due to automatic updates of the host OS? They might happen while the upload to S3 is in progress. Is there anything in the logs of your OS? Maybe reset the backup_time_of_day site setting to the default value or a different time and see if the problem disappears.

1 Like

No, current uptime is 36 days. I had suspected that the DigitalOcean droplet backup running concurrently might have been the cause, but that happens once a week and my undeleted backups occur more frequently than that.

I’ll try a different backup_time_of_day. It was set to 2:00 UTC, so we’ll see if the default 3:30 UTC makes any difference.

2 Likes

OOOOH! That’s a good one. That would explain it. I bet that’s it. And the middle of the night is a Good Time for both backups and reboots. It doesn’t quite explain why the problem went away when I changed to a different service, but maybe my luck just changed, or whatever I changed to was faster or something.

Oh. Darn. :crying_cat_face:

Sixteen days later, it seems like this was the solution—no more undeleted backups. I don’t know what was causing the conflict, but it’s moot now.

1 Like