In the past when I clicked the Download button on the backups screen, the browser downloaded the file. Now the tooltip reads “Send email with download link” and it emails me with a link to download it. Is that new behavior that I just missed or is there an issue with my install?
Yes, that is new behavior added to increase the security of the backups. I’m looking for the relevant topic now…
Edit: Here you go:
So. I have four Discourse forums. I like to download my backups daily, for each. In each case, I must navigate to the “backups” page, click on the download link, switch over to my e-mail program, wait for the message to arrive, and click on the link that’s provided? Every day?
I understand the need for security (and that’s one reason I don’t use SSO at all!), but this sucks.
Given this convoluted workflow, is there some way that I could easily bypass all of this and automatically download the most recent backup for each of my sites daily?
Have you considered having your uploads automatically backup to S3? If you want to take backups every day that’s even simpler than logging in to download them.
Thanks, @eviltrout, I may look into that. I’ve usually stayed away from Amazon’s services, and so had forgotten that this was a baked-in option.
(Logging in hasn’t been an issue, as I’m a moderator on each of the forums anyway, and have browser tabs for them pinned open — so downloading the automatic backups been dead easy.)
We are also going to be adding more cloud providers for automatic backups in the future via the Rails Girls Summer of Code project, if Amazon isn’t your thing.
The best kinds of backups are the ones you don’t have to do anything about 
Yeah, and Dropbox Backups already works.
Is there a way to disable this feature? I used to download backups automatically to a server in my control by inspecting /admin/backups.json using an admin API token (of an account which doesn’t have an email address in the first place).
I’d be more interested in being able to set an encryption key for the backups. If someone manages to steal the API key for my backup bot then I could still rest relatively easy knowing the private key is only on the backup download server, which doesn’t face the internet apart from downloading the backups.
I understand the security implications, however, I’d consider storing (unencrypted) backups on someone else’s server to be more dangerous than the risk of someone obtaining the API key for my bot (which resides only on a system I have physical control of, and does not act as a server). Making Discourse push backups to the system would be less optimal for me as that would mean I had two internet-facing servers to worry about instead of one.
There’s no way to disable this feature, and because we want to be very secure by default I can’t see us allowing a user to do that any time soon. You could build a plugin that allows you to access the backups directly.
The encryption key is not a bad idea as a separate feature, but it wouldn’t mean we’d pull back this feature.
Sorry for the late reply.
Oh yeah, allowing a user to disable the feature kind of makes the feature meaningless I suppose, hadn’t thought of it that way.
Then I’ll consider making a plugin .Thanks for the quick response and suggestion!
We had an issue here because it made it much harder to download a backup from a (third party) provider where we don’t have shell access, and upload it to one of our own servers. Especially when handling a large backup and both servers are in the USA (we’re in Europe) this process was costing us hours instead of minutes.
Somehow the backup link does not work with an api_key so a simple wget will not work 
We made a small script that can be called from the command line. It needs three parameters:
- username
- password
- download link from the email, including the token
So something like
./download.sh myuser mypass https://forum.mysite.com/admin/backups/mysite-2017-05-31-113000-v20170526125321.tar.gz?token=d31de61bc07f7bc9060717bc57828584
Here is the script:
#!/bin/bash
USERNAME=$1
PASSWORD=$2
URL=$3
HOSTNAME=$(echo $URL | awk -F/ '{print $3}')
TOKEN=$(
curl \
--header "X-Requested-With: XMLHttpRequest" \
-A "MSIE" \
-b cookies.txt \
-c cookies.txt \
-v\
https://$HOSTNAME/session/csrf|awk -F: '{print $2}'|cut -c2-89
)
echo "Using Token $TOKEN Username $USERNAME Password $PASSWORd"
curl \
--header "X-Requested-With: XMLHttpRequest" \
--header "X-CSRF-Token: $TOKEN" \
--header "Origin: https://$HOSTNAME" \
-A "MSIE" \
-b cookies.txt \
-c cookies.txt \
-v\
--data "login=$USERNAME&password=$PASSWORD" \
https://$HOSTNAME/session
curl \
-A "MSIE" \
-b cookies.txt \
-c cookies.txt \
-O \
$URL
One more suggestion: would it be an idea to exclude the email with the link from being affected by the disable_email setting?
I think it a quite bad idea.
Because the browser downloader usually stops at some time. The backup package is quite big usually, but if we only have one chance to download and then the link will pastdue, usually it will download half and stoped there.
Can you support breakpoint resume download? If not, you’d better think of a better way to help people successfully download the whole package with the browser.
저도 같은 문제를 겪고 있습니다. 개인적인 이유로 이 기능을 비활성화해야 합니다.
기본적으로 매우 안전한 설정을 원한다는 점은 이해합니다. 하지만 비기본 옵션을 제공할 수는 없을까요?
아니면 링크를 새로운 대상 이메일 주소로 보내는 옵션을 추가할 수는 없을까요?
기본 옵션으로 활성화하도록 설정하는 데 강력히 동의합니다.
비활성화하거나 기본값으로 설정하지 않을 수 있는 기능이 많습니다. 아마도 그 기능이 의미 없는 것은 아닐 것입니다.
이메일 링크가 있든 없든 그것이 여기서 주요 문제는 아닙니다. 이제 우리는 백업 다운로드가 실제 문제의 해결책이었으며, 그 문제는 과거에도 현재에도 여전히 너무 드물게 백업을 한다는 점이었다는 것을 기억해야 합니다.
저는 웹스토어의 데이터베이스를 5분마다 백업합니다. 제 CMS는 매시간 백업을 수행합니다. Discourse의 경우 네이티브로 얻을 수 있는 가장 최신 백업은 하루에 한 번뿐입니다. 즉, Docker나 MySQL/MariaDB 이외의 다른 기술에 익숙하지 않아서, 24시간이라는 시간 창 내에서 문제가 발생하면 일부 콘텐츠를 잃을 위험을 매일 감수하고 있다는 뜻입니다.
실제로 그런 일이 한 번 일어난 적이 있습니다.
현재 이메일 링크 방식은 네트워크가 제한된 지역에서 백업을 다운로드할 때 VPN을 일정 시간 동안 사용하더라도 항상 30%에서 멈췄습니다.
그때도 여전히 이메일 링크만 지원된다면, 나중에 비슷한 문제가 발생할 것입니다.
자체 호스팅(self-hosted)을 사용하고 있으며 백업을 다운로드하려면 ssh/scp를 통해 수행할 수 있습니다. 또 다른 옵션은 백업을 S3에 저장하는 것입니다. 웹 브라우저를 통해 다운로드하는 것은 프로세스를 자동화하는 신뢰할 수 있는 방법이 아닙니다.
그런 수준의 시간 역행(time travel) 기능을 원한다면, postgres를 롤백을 허용하도록 구성하거나 실시간 백업 서버를 갖추는 것이 좋습니다.