Thanks for the hint. That pushed me towards the command line option which we can schedule to do whenever: 
2 个赞
我实现了这个功能，但似乎上传复选框并非必需，我也不明白它的用途。它的用途是什么？ 我唯一想要的是将备份存储到 S3 而不是服务器本地。服务器只有每周自动备份。
JSON 也存在问题。我使用另一个网站的参考才得以实现。但是，由于我勾选了上传复选框（如此处所述），没有人能够上传任何图片。取消勾选该框可以解决用户及其个人资料图片的上传问题。
图片上传的用途是什么？我非常希望图片包含在 S3 备份中。
我不得不重复两次说明，因为我不理解“上传”的含义，只创建了一个存储桶。然后我不得不再次创建两个存储桶，然后我不得不取消勾选上传复选框。如果有一个单独的、更简单的关于 S3 备份的主题会更好，而且只包含备份。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:List*",
"s3:Get*",
"s3:AbortMultipartUpload",
"s3:DeleteObject",
"s3:PutObject",
"s3:PutObjectAcl",
"s3:PutObjectVersionAcl",
"s3:PutLifecycleConfiguration",
"s3:CreateBucket",
"s3:PutBucketCORS"
],
"Resource": [
"arn:aws:s3:::classicaltheravadabucket",
"arn:aws:s3:::classicaltheravadabucket/*",
"arn:aws:s3:::classicaltheravadabackupbucket",
"arn:aws:s3:::classicaltheravadabackupbucket/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:*"
],
"Resource": "*"
}
]
}
2 个赞
不过我认为该主题应该更新，建议将 S3 配置移至 app.yml 而不是数据库，这样您就可以通过命令行恢复数据库，而只需使用 yml 文件，而无需在恢复之前使用用户和 s3 配置进行配置。
1 个赞
我不确定您在说什么。我的备份正在工作，请看图片。
我使用 s3 是因为 DigitalOcean 的备份只是一周一次，如果服务器崩溃并被删除，那将毫无用处。
另一方面，我希望从 s3 或下载的 s3 存储桶恢复将没问题。
我没有上传图片，我希望 s3 备份包含图片（尽管很少）。
一般来说：不。
将 S3 存储桶中的图像备份到另一个 S3 存储桶没有多大意义？
2 个赞
你能更明确一点吗？
说明中有两个 S3 存储桶。我无法使其正常工作。
我只有一个 S3 存储桶。希望图片包含在该备份中……这是正确的吗？
我想本地备份也应该一样，对吧？
请用完整的句子回答我的问题。教程也非常令人困惑。
1 个赞
“不”有什么歧义？（“备份被备份”又有什么不含糊的呢 
）
我再试一次。
如果您已将上传配置为使用 S3，则上传不包含在您的备份中。
2 个赞
让我们使用“图片”一词而不是“上传”，即使它可以是其他媒体。
这样我们就不会将文本内容与我上传到 s3 的内容混淆。
那么，s3 中 62 MB 的备份文件，如图所示并在此线程中上传的，不包括图片吗？
那么我如何确保备份包含这些呢？
本地备份也包含图片吗？
当我配置 s3 用于“上传（媒体）”时，这也含糊不清。没有人能够发布图片，因为它们被 s3 拒绝了……
有没有办法同时进行本地和 s3 的每日备份？
我不在乎丢失 5 天的图片，我们主要是一个基于文本的群组。
但我会在乎丢失 5 天的文本。Digital Ocean 如果你付费，只会提供 7 天的备份。
所以即使我可以每天备份，如果液滴被黑客攻击或损坏，那么我们就会丢失那些备份……我开始认为 s3 并没有增加多少价值。
我希望有类似 WordPress 的简单备份，可以让我备份到我的 Google 或 Dropbox 帐户。
不，这是个坏主意，如果你将文本文件作为附件上传，它也是一个上传，这会引起混淆。而且帖子中的文本存储在数据库中。所以我坚持使用“上传”这个词。
如果你的上传在 S3 上，它们就不包含在备份中。在这种情况下，备份只包含数据库的副本。无论你的备份是本地的还是在 S3 上的，都没有关系。
如果你的上传不在 S3 上，它们就包含在备份中。在这种情况下，备份包含数据库的副本和上传的副本。无论你的备份是本地的还是在 S3 上的，都没有关系。
如果你将某些东西存储在 S3 上，无论是上传还是数据库备份，如果你的 DO 服务器被黑客攻击或损坏，它们都不会丢失。所以我没明白你的意思。
由于你的帖子是关于备份而不是关于文件和图片上传的，我将把它们移到另一个主题。
3 个赞
如果有人执行了这些步骤并且了解情况，我可以再问一遍吗？
另外，您知道是什么导致了 S3 费用出现这些波动吗？
此外，自论坛启动（2020 年 9 月）以来，备份大小增加了约 15%，但 S3 账单却翻了一番，从 2.50 美元增至 5 美元。您知道为什么会增加这么多吗？
这就是为什么我想使用 Glacier。
编辑：我已经按照此处所述的步骤进行操作，我会看看效果如何。
1 个赞
嗯，效果不佳。 
我的生命周期配置：
我的 S3 存储桶：
没有备份在 Glacier 中。
那么……对于那些能够实现 S3 到 Glacier 自动转换的人，我有两个问题：
-
我的配置可能有什么问题？
-
Glacier 的最低存储时长收费是 90 天。这意味着如果我每天备份 1 次，最终每个月会为 Glacier 中的 90 次备份收费吗？
如果是这样，那么 Glacier 解决方案将不是一个好主意，除非我大大降低备份频率。
1 个赞
备份存储在 VPS 的哪个位置？
1 个赞
我已将此添加到OP：
2 个赞
我们可以选择备份文件夹，或者有没有无需编码的解决方法？
我正在使用托管提供商的存储数据，可以挂载并像本地一样使用，但它不应该保存在默认路径中。
1 个赞
如果您希望将其保存在其他位置，则需要在您的 app.yml 中进行更改。
2 个赞
Backblaze B2 自动备份
以下是我为托管在 example.com 上的假设站点设置的方法：
- 在 Backblaze 上创建一个账户（目前，10GB 以下免费，无需输入付款信息）。
- 创建一个存储桶（Backblaze > B2 Cloud Storage）
- 名称：
$sitename-discourse-$random，填充至 30 个字符- 在此示例中：
example-discourse-g87he56ht8vg - Discourse 需要存储桶名称仅包含小写字母、数字和连字符。
- 我建议将其保持在 30 个字符或更少，这样在 Backblaze 的 Web UI 中显示效果更好，不会换行。
- 在此示例中：
- 私有存储桶
- 启用加密（SSE-B2）
- 启用对象锁定
- 名称：
- 创建一个应用程序密钥（Backblaze > Account > App Keys）
- KeyName：
example-discourse - BucketName（允许访问存储桶）：
example-discourse-g87he56ht8vg - Capabilities：Read 和 Write
- 将 Name Prefix 和 Valid Duration Seconds 留空
- KeyName：
- 配置 Discourse B2 设置（Discourse > Admin > Settings）
backup_location:s3s3_backup_bucket:example-discourse-g87he56ht8vgs3_endpoint: 在存储桶页面上显示 - 确保以https://开头s3_access_key_id:（来自上一步）s3_secret_access_key:（来自上一步）- Backblaze 只会显示一次密钥（创建时）！
- 另外，您也可以在容器的 yml 文件中将其设置为环境变量（https://meta.discourse.org/t/best-practices-for-backups/148630）。这样您只需该文件即可恢复，无需其他任何内容：
env:
## Backblaze B2 Backups
# DISCOURSE_BACKUP_LOCATION: 's3' # 取消注释以从 CLI 恢复
DISCOURSE_S3_ENDPOINT: 'https://....backblazeb2.com'
DISCOURSE_S3_BACKUP_BUCKET: 'example-discourse-g87he56ht8vg'
DISCOURSE_S3_ACCESS_KEY_ID: '...'
DISCOURSE_S3_SECRET_ACCESS_KEY: '...'
# DISCOURSE_DISABLE_EMAILS: 'non-staff' # 取消注释以在测试恢复期间禁用电子邮件
## 您可以使用此容器 YML 以外的任何数据进行恢复。
## 取消注释上面的 DISCOURSE_BACKUP_LOCATION，构建容器（./launcher rebuild ...），
## 然后在容器内运行此命令（它将从 B2 存储桶恢复）：
## discourse enable_restore
## discourse restore <example-com-...tar.gz> # 通过浏览 B2 Web UI 选择恢复文件名
## 记得之后禁用恢复
- 配置备份保留策略
- Discourse：
backup_frequency: 1（此示例中为每日备份，但您也可以选择每周）maximum_backups: 忽略此设置 - 让 Backblaze 处理
s3_disable_cleanup: true（防止在备份数量超过允许的最大值时从 S3 中删除旧备份）
- Backblaze（转到您的存储桶设置）：
- Object Lock（默认保留策略）：7 天
- Lifecycle Settings（自定义）：
fileNamePrefix:default/example-com（可选）daysFromUploadingToHiding: 8 天- 这应该是 Object Lock + 1
daysFromHidingToDeleting: 1 天
总结此示例中的保留策略：
- Discourse：
- Discourse 每 1 天创建一个备份。
- 每个备份文件在上传到 B2 后 7 天内不可变（对象锁定）。这可以防止意外、勒索软件等。
- 上传后 8 天，备份上的对象锁定将过期。由于它再次变为可变，生命周期规则可以隐藏备份文件。
- 生命周期规则的下一部分将在隐藏后 1 天删除任何文件。
因此，您将获得每日备份。保留时间为一周，在此期间无论如何都无法删除备份。然后备份将在 2 天后删除。所以实际上一个备份会保留大约 9 天。
希望这对大家有帮助 
仔细想想，也许让 Discourse 处理保留策略（maximum_backups）更好。这样，如果 Discourse 出现故障，您的备份也不会自动开始过期。您不希望在尝试恢复时时钟还在滴答作响。如果采用这种方式，您可以设置 maximum_backups=8 和 s3_disable_cleanup=false（此示例中）并且不使用 B2 中的生命周期策略。但您仍然会使用对象锁定策略（7 天）。
编辑：实际上，我认为您仍然需要一个 B2 生命周期策略，因为我认为当 S2 客户端删除文件时，文件只会“隐藏”而不会被删除。我使用的是“只保留文件的最后一个版本”策略，这等同于 daysFromHidingToDeleting=1, daysFromUploadingToHiding=null。
我想您需要仔细考虑并决定哪种方法适合您。
顺便说一句，我意识到这篇帖子有些来回。我认为它本身就很有信息量，但如果有人愿意，我可以发布一篇更简单的帖子，其中包含我的实际建议。
6 个赞
如果您按照为上传配置 S3 兼容对象存储提供商中的描述将它们放入环境变量中，那么您只需使用 yml 文件即可从命令行将您的站点恢复到新服务器。
其余部分看起来是个不错的计划。
3 个赞
discourse restore <backup.tar.gz>
this will look in your bucket if you have the env vars set? pretty cool if so.
and in that case, you could probably also set them manually with export in bash in the unlikely event that you have to recover. that is, if you don’t want to keep secrets in your container yml for some reason.
1 个赞
只是为了确认，一旦我迁移到 S3 备份并测试它们是否正常工作，我是否可以安全地删除该文件夹的内容以回收已用空间？