honeymoose
(HoneyMoose)
1
Discourse 与 S3 是对好基友,如果你对 S3 比较熟悉的话,那么对你来说帮助会非常大。
很多人的虚拟主机空间是有限并且资源也是有限的。
使用 S3 进行备份能够更好的利用空间。
你可以按照下面的步骤进行配置:
设置备份频率
进入 admin > backup,然后设置 backup_frequency 为 1。这个是参数是表示备份的频率,默认为 7 。
1 表示的是每天进行备份一次。
7 表示的是每 7 天进行备份一次。
针对一般访问网站,如果使用 S3 进行存储备份的,最好还是每天备份一次。
![](https://d11a6trkgmumsb.cloudfront.net/original/4X/8/e/3/8e37974a1263582bd017fbceee7c02f7d984e986.jpeg)
设置备份的 Bucket 和路径。
这个 Bucket 可以是私有的不公开的,这里需要注意的是,如果你还使用了 S3 为图片和附件存储的话,那么那个 Bucket 在设置的时候是需要选择 public。
为了方便,你可以在这里另外创建一个 bucket,尽量不要和附件和图片的存储搞混了。
我们建议你在这里多设置一个目录路径,因为 Discourse 会在这个文件夹下面创建多个需要的文件夹。
以便于你的存储更加清晰和明确。
设置 s3_access_key_id 和 s3_secret_access_key
下一步,你需要为你存储的备份数据设置:s3_access_key_id
和s3_secret_access_key
以及s3_region
。这 3 个参数非常重要,region 不能选错了。如果你的备份上传不上去,那么绝大部分情况可能是权限的问题。
具体的设置方法请参考: Setting up file and image uploads to S3 - sysadmin - Discourse Meta 文章中的内容。
需要注意的是,这里你需要为你的 key ID 赋予足够的权限,否则你将没有办法上传。
![](https://d11a6trkgmumsb.cloudfront.net/original/4X/4/2/7/42745097abccd5cf9c450bd40fc15d57d5e16194.jpeg)
将备份设置为 S3 存储
将备份的方式设置为 S3 存储。
你需要在这个参数选择部分,将 Local 的存储修改为 S3 存储。
![](https://d11a6trkgmumsb.cloudfront.net/original/4X/d/c/2/dc29c6f1e2ebbc320d60966fde29b6edb4638d31.jpeg)
测试备份
当一切都设置好以后,你可以进行测试备份。
单击备份按钮进行测试备份。在备份的菜单中,直接单击 Buckup 就可以了。
在弹出的界面中会询问你是否包含上传的图片和附件。
一般来说都会在这里选择 Yes。随后界面会跳转到日志界面中,然后会将备份的信息通过日志显示出来。你可以通过观察日志是否显示 Finished 来确定备份是否已经完成。
更重要的是你可以登录你的 S3 账号,确定已经有最新的备份了。
![](https://d11a6trkgmumsb.cloudfront.net/original/4X/4/9/f/49ff84cf511270c31acea663e7eefd9b2e33b59c.jpeg)
你需要注意下时间,大小和文件名进行确认就可以了。
![](https://d11a6trkgmumsb.cloudfront.net/original/4X/9/0/e/90ed6a973369af122a88b7fb67c4cd1fbdb859c8.jpeg)
通过设置 S3 的备份,我们能够扩展 Discourse 的存储空间,几乎获得无限的备份和无限的存储空间。对网站运营来说,自动备份和上传是非常实用的功能。
同时你也有多个存储的备份,便于你对网站进行恢复的时候恢复到不同的备份点。
因为你将备份文件,从 Docker 上分离了,这个对你日常备份非常有帮助。能够大量降低存储空间的使用。
我们同时建议将图片和附件也存储到 S3 上面,这样对你迁移,备份恢复都有非常大的优势。
请参考原文 iSharkFly - 鲨鱼君 了解更多内容。
2 Likes
我想问一下,备份和附件分别挂载了不同的S3 备份的时候会把附件的S3里面的内容也都一起备份了吗?如果不选择包含上传的图片和附件,那么恢复备份的时候,附件用的S3里面的内容还能再论坛里正常显示吗
针对 Discourse 的备份内容还真没有仔细查看。
看了下我们的备份后才了解到:
如果你的附件是使用 AWS 的云存储的话,备份的时候哪怕选择上 备份时包含附件
![](https://d11a6trkgmumsb.cloudfront.net/original/4X/4/9/d/49d26cc0a3ee397e1a7adaa22303c978a3ceab81.png)
上传到 AWS 上的附件也是不会放在你的备份文件里面的。
里面的附件就是存储在你本地计算机上,但是 AWS 上没有的内容。
从我们的网站备份大小上就能看出来,如果包含附件的话,备份的大小不可能只有 80 多 MB。
![](https://d11a6trkgmumsb.cloudfront.net/original/4X/f/9/b/f9b79370ec9b2801c89ee529cfc335c0b0d02e6e.png)
说明这里面的备份只有数据库和本地附件。
打开这个下载文件,看到里面只有 2 个文件夹,一个是 dump,这个就是 PGSQL 的数据库 Dump 文件。
另外一个就是上传的文件夹,这个文件夹里面只有你本地上传的附件,没有存储到 AWS 上面的,对我们来说这个文件夹就很小,没有几个文件。
这是因为在社区开始运行没有多久后我们就全部把附件上传到 AWS 上了。
![](https://d11a6trkgmumsb.cloudfront.net/original/4X/b/a/8/ba83b66e1247d6df636983117d306f8ea9bbfc50.png)
上图显示的是 PGSQL 的 Dump 文件内容,可以从 dump 文件中看到当前 Discourse 数据库容器运行的 PGSQL 版本。
如果你想本地看下数据库的话,这个 Dump 文件也可以直接导入到你本地容器上的。
AWS 恢复的问题
如果使用了 AWS 附件,但是没有使用 AWS 的 CDN 的话,那么正文中的内容就是你 AWS 上的绝对路径地址。
在主题 MD 文件上的表现方式为:
但是,当内容发布后,实际的 HTML 代码就被 Discourse 替换成你的 CDN 绝对地址了。
![](https://d11a6trkgmumsb.cloudfront.net/original/4X/7/7/b/77b5f21ca4b8d2be511f98c42a22da156a2696ed.png)
因此,基于上面的回答,在备份的时候如果不选择备份附件,当你恢复的时候,附件的内容不受影响。
例外
其实附件也有受到影响的,主要就是因为域名切换。
因为前期我们有过一次域名切换,但附件内容都在,就是正文无法关联,就算重构 HTML 也无法关联。
这个时候麻烦点,可能需要到数据库里面直接改一下。
只要你不随便换域名,通常这个都不是问题。
更详细的讨论,请访问:Discourse 备份和恢复中有关附件的问题 - Discourse - iSharkFly
我想顺便问一下另外的问题,我没有使用亚马逊云S3 而是用了cloudflare的R2 而且我已经成功的备份到R2里面 可以在cloudflare里面看到文件 但是我在discourse的后台没有显示备份的文件 请问是哪里出了问题
再手动备份一次,查看备份的日志。
这里多半是因为 Discourse 调用 R2 存储备份后的状态查看部分 API 有错误。
你看看日志上面的内容全不全。
这是刚刚生成的截图,貌似显示一切正常,另外我在R2创建的是最高权限的API。
运行了下我的备份过程,貌似我们的日志是相同的。
[2024-07-26 11:56:00] pg_dump: executing SEQUENCE SET category_custom_fields_id_seq
[2024-07-26 11:56:00] Finalizing backup...
[2024-07-26 11:56:00] Creating archive: isharkfly-2024-07-26-115540-v20240723030506.tar.gz
[2024-07-26 11:56:00] Making sure archive does not already exist...
[2024-07-26 11:56:00] Creating empty archive...
[2024-07-26 11:56:00] Archiving data dump...
[2024-07-26 11:56:00] Archiving uploads...
[2024-07-26 11:56:00] Skipping uploads stored on S3.
[2024-07-26 11:56:00] Removing tmp '/var/www/discourse/tmp/backups/default/2024-07-26-115540' directory...
[2024-07-26 11:56:00] Gzipping archive, this may take a while...
[2024-07-26 11:56:05] Uploading archive...
[2024-07-26 11:56:09] Executing the after_create_hook for the backup...
[2024-07-26 11:56:09] Deleting old backups...
[2024-07-26 11:56:10] Cleaning stuff up...
[2024-07-26 11:56:10] Removing archive from local storage...
[2024-07-26 11:56:10] Removing '.tar' leftovers...
[2024-07-26 11:56:10] Marking backup as finished...
[2024-07-26 11:56:10] Refreshing disk stats...
[2024-07-26 11:56:10] Notifying 'honeymoose' of the end of the backup...
[2024-07-26 11:56:18] Finished!
那下一步看看是不是数据库备份表的记录的问题。