The (manual) backup (didn't) failed

(PJH) #1

Manually instigated backup via:



  1. It doesn’t actually appear to have failed - the tarball produced appears to be intact and has what I expected in it (the sql dump. Also had a meta file in there.)
  2. Which logs? The one that’s visible in that screenshot? No indications there. /logs? Can’t find anything there around the time of the backup actually relating to the backup.
  3. I didn’t get notified - or if I was, I’ve no idea where to look for it.
  4. [Invalid date] in the log in the screenshot.

(Régis Hanol) #2

Might have failed uploading the backup to S3 if that is enabled.

Yes, the one that’s visible in that screenshot. You have to scroll back up to pass the rather large stacktrace to see more details about the exception.

Should be in a private message.

That’s indeed curious. Might be related to the bug.

(PJH) #3

What’s the (without upload) part of the button mean then?

There was nothing obvious - but know I know it’s that one I’ll try again later…

Certainly not received then.

(Régis Hanol) #4

Means that the generated archive doesn’t include any of the uploaded files (images/attachments/avatars/thumbnails).

(cpradio) #5

Ahhh… I would not have guessed that. :smile: I thought the same lines as @PJH, that it meant it wouldn’t get uploaded to your S3 setup.

(PJH) #6

May I suggest re-wording it for clarity then? Yes (SQL DB only) perhaps? (And perhaps the other Yes (Everything))

(Jeff Atwood) #7

Simpler fix is just to change the copy from

Without Upload


Without Files

Though I like your “everything” idea too.

(Jeff Atwood) #8

OK, I changed it to

Yes (do not include files)

Which I think is 100% crystal clear.

(lid) #9

(Jeff Atwood) #10

“DB only” is just technospeak. I don’t support that.

(lid) #11

No argue about that.

But notice the change in the ui that can better express and control the type of backup.

(Sam Saffron) #12

I think the new copy change is fine. Let’s just watch this and see if anyone else complains. Its much clearer than what it was.

(PJH) #13

After update:

Full log: Discourse backup failure -

[Invalid date] Gzipping archive...
[Invalid date] Executing the after_create_hook for the backup
[Invalid date] Removing old backups...
[Invalid date] EXCEPTION: Expected(204) <=> Actual(403 Forbidden)
  :body          => "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<Error><Code>AccessDenied</Code><Message>Access Denied</Message><RequestId>EC17C3587840D309</RequestId><HostId>elided</HostId></Error>"
  :headers       => {
    "Content-Type"     => "application/xml"
    "Date"             => "Fri, 03 Oct 2014 08:20:29 GMT"
    "Server"           => "AmazonS3"
    "x-amz-id-2"       => "elided"
    "x-amz-request-id" => "elided"
  :local_address => ""
  :local_port    => 36184
  :remote_ip     => "elided"
  :status        => 403

[Invalid date] /var/www/discourse/vendor/bundle/ruby/2.0.0/gems/excon-0.39.6/lib/excon/middlewares/expects.rb:6:in `response_call'
/var/www/discourse/vendor/bundle/ruby/2.0.0/gems/excon-0.39.6/lib/excon/middlewares/response_parser.rb:8:in `response_call'

That would appear to be the problem, though having spoken (on the truncated downloads issue) with Alex previously about backups, the daily ones are getting uploaded. Or were… I’ll check up on it.


  1. I still didn’t get a notification.
  2. “Invalid Date”

(Sam Saffron) #14

I wonder if the backing up is somehow triggering the weird encoding errors.

(PJH) #15

… I’m not doing backups quite that frequently… :wink:

(Sam Saffron) #16

But… we have automatic daily backups, not sure, just an idea … its really weird, but making progress on that issue.

(Jeff Atwood) #17

Regardless, can’t repro on my DO instance, manual backups work fine, just tested:

[2014-10-08 12:36:18] Removing tmp '/var/www/discourse/tmp/backups/default/2014-10-08-193512' directory...
[2014-10-08 12:36:18] Unpausing sidekiq...
[2014-10-08 12:36:18] Marking backup as finished...
[2014-10-08 12:36:18] Finished!

Per Sam’s comments, this is the other weird encoding issue, not related to backups.

(Also, I do suggest you download the daily automated backups rather than creating a new backup, unless there is some urgency around having the last few hours of data present in the backup.)

Deliberately created partial backups for local Postgres queries
(Jeff Atwood) #18