honeymoose
(HoneyMoose)
1
Discourse 与 S3 是对好基友，如果你对 S3 比较熟悉的话，那么对你来说帮助会非常大。
很多人的虚拟主机空间是有限并且资源也是有限的。
使用 S3 进行备份能够更好的利用空间。
你可以按照下面的步骤进行配置：
设置备份频率
进入 admin > backup，然后设置 backup_frequency 为 1。这个是参数是表示备份的频率，默认为 7 。
1 表示的是每天进行备份一次。
7 表示的是每 7 天进行备份一次。
针对一般访问网站，如果使用 S3 进行存储备份的，最好还是每天备份一次。
设置备份的 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 赋予足够的权限，否则你将没有办法上传。
将备份设置为 S3 存储
将备份的方式设置为 S3 存储。
你需要在这个参数选择部分，将 Local 的存储修改为 S3 存储。
测试备份
当一切都设置好以后，你可以进行测试备份。
单击备份按钮进行测试备份。在备份的菜单中，直接单击 Buckup 就可以了。
在弹出的界面中会询问你是否包含上传的图片和附件。
一般来说都会在这里选择 Yes。随后界面会跳转到日志界面中，然后会将备份的信息通过日志显示出来。你可以通过观察日志是否显示 Finished 来确定备份是否已经完成。
更重要的是你可以登录你的 S3 账号，确定已经有最新的备份了。
你需要注意下时间，大小和文件名进行确认就可以了。
通过设置 S3 的备份，我们能够扩展 Discourse 的存储空间，几乎获得无限的备份和无限的存储空间。对网站运营来说，自动备份和上传是非常实用的功能。
同时你也有多个存储的备份，便于你对网站进行恢复的时候恢复到不同的备份点。
因为你将备份文件，从 Docker 上分离了，这个对你日常备份非常有帮助。能够大量降低存储空间的使用。
我们同时建议将图片和附件也存储到 S3 上面，这样对你迁移，备份恢复都有非常大的优势。
请参考原文 iSharkFly - 鲨鱼君 了解更多内容。
2 Likes
我想问一下，备份和附件分别挂载了不同的S3 备份的时候会把附件的S3里面的内容也都一起备份了吗？如果不选择包含上传的图片和附件，那么恢复备份的时候，附件用的S3里面的内容还能再论坛里正常显示吗
针对 Discourse 的备份内容还真没有仔细查看。
看了下我们的备份后才了解到：
如果你的附件是使用 AWS 的云存储的话，备份的时候哪怕选择上 备份时包含附件
上传到 AWS 上的附件也是不会放在你的备份文件里面的。
里面的附件就是存储在你本地计算机上，但是 AWS 上没有的内容。
从我们的网站备份大小上就能看出来，如果包含附件的话，备份的大小不可能只有 80 多 MB。
说明这里面的备份只有数据库和本地附件。
打开这个下载文件，看到里面只有 2 个文件夹，一个是 dump，这个就是 PGSQL 的数据库 Dump 文件。
另外一个就是上传的文件夹，这个文件夹里面只有你本地上传的附件，没有存储到 AWS 上面的，对我们来说这个文件夹就很小，没有几个文件。
这是因为在社区开始运行没有多久后我们就全部把附件上传到 AWS 上了。
上图显示的是 PGSQL 的 Dump 文件内容，可以从 dump 文件中看到当前 Discourse 数据库容器运行的 PGSQL 版本。
如果你想本地看下数据库的话，这个 Dump 文件也可以直接导入到你本地容器上的。
AWS 恢复的问题
如果使用了 AWS 附件，但是没有使用 AWS 的 CDN 的话，那么正文中的内容就是你 AWS 上的绝对路径地址。
在主题 MD 文件上的表现方式为：
但是，当内容发布后，实际的 HTML 代码就被 Discourse 替换成你的 CDN 绝对地址了。
因此，基于上面的回答，在备份的时候如果不选择备份附件，当你恢复的时候，附件的内容不受影响。
例外
其实附件也有受到影响的，主要就是因为域名切换。
因为前期我们有过一次域名切换，但附件内容都在，就是正文无法关联，就算重构 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!
那下一步看看是不是数据库备份表的记录的问题。
