Network error on backup download

Bug
1

My co-admin told me he couldn’t download a backup from the received email because the download crashed at roughly 50%.

I tried and experienced the same. The archive download works well until it stops with “Failed - Network error”.
Trying to resume on Chrome returns “Failed - Unknown server error”. I had no issue the last time I downloaded backups from this server (months ago). (this is expected)

Any idea?

edit, more info:

Repro steps:

  1. Download a backup from the emailed link
  2. The download should fail at some point
2

Hi,

I’m Canapin’s co-admin :slight_smile:

Trying to resume on Chrome returns “Failed - Unknown server error”. I had no issue the last time I downloaded backups from this server (months ago).

I’m wondering whether this is due to the one-time link. You can’t download a backup twice with a single link. So, when it fails once, resuming the download is probably cancelled by Discourse itself.

1 Like
3

i think you need to change the way you’re downloading the backup

1 Like
4

Well, there sure are other ways to download backups, but I’d rather identify the cause and fix this particular issue :smile:

1 Like
5

probably this, but this is not the only issue preventing full download of the backup via web browser

6

As an update, the forum was migrated to another server (for unrelated reasons), but the issue persists. The backup download (3.3 GB) always fails.

7

I tried downloading a backup from another forum and experienced the same.

Can someone try to replicate on their own instance? On both sites the download fails after 30 seconds.

Moving this to Bug because I’m quite sure this is not just me.

8

I have been experiencing this same issue for over a week. Fully updated twice in that time but the issue still persists. Self-hosted on IONOS. Backup size 1.5GB.

2 Likes
9

I’ve submitted a PR to address this by increasing the Nginx timeouts specifically for /admin/backups/, which should help prevent mid-stream “Failed – Network error” drops during larger downloads:

1 Like
10

Tried again just now. Still failing at 1GB

1 Like
11

This is way too risky, it can open up risk for unintended denial of service.

We should be using sendfile there and nginx should handle it without any proxy needs.

1 Like
12

Fully updated 2025.12.0-latest, issue persists.

Edit: I can download the backups via WinSCP or something like that but it would be nice if it worked as advertised and the email link + browser download completes successfully.

AI is probably wrong but also advising to increase the: DISCOURSE_NGINX_PROXY_READ_TIMEOUT: 600 to resolve this issue.

1 Like
13

I’m getting this as well. 13GB backup size (my last full backup before offloading all media to S3 before anyone complains!)

1 Like
14

wow! this is definitely the size to be doing over SSH rather than the web browser

15

Regardless of what should be the right way to do something, we’re just highlighting the fact that a useful built-in feature is currently broken :slight_smile:

2 Likes
16

i was being sarcastic

the python script below won’t continue to work after enabling secure-media though

17

Might I suggest some helpful text telling admin file location of backup incase they want to download with a client?

Wouldn’t have found it without @Ethsim2 earlier post

18

/var/discourse/shared/standalone/backups/default/your_backup_filename.tar.gz

19

Also this button is misleading - it would be better labelled as ‘Email Download Link’

image
image1470×422 20.7 KB

20

It doesn’t know. It can’t know. It depends on your docker configuration in your yml file. It’s usually in standalone, but it could be in web_only, but it could also be anywhere in the file system.

While that’s technically true, I don’t remember anyone else expressing that concern in the past decade. Do you find it very misleading? You can change it on your own site if you think it’ll help.

2 Likes