Thanks for the hint. That pushed me towards the command line option which we can schedule to do whenever: 
「いいね！」 2
これが機能しましたが、アップロードチェックボックスは実際には必要なく、その目的も理解できませんでした。目的は何ですか？ 私が望むのは、サーバーのローカルではなくS3へのバックアップのみです。サーバーには週に1回の自動バックアップしかありません。
JSONにも問題がありました。別のウェブサイトの参照を使用して機能させることができましたが、アップロードチェックボックスをオンにしていたため（ここで説明されているように）、誰も画像をアップロードできませんでした。そのボックスをオフにすると、ユーザーとそのプロフィール写真の画像アップロードの問題が解決しました。
画像のアップロードの目的は何ですか？画像がS3バックアップに含まれていることを真剣に願っています。
指示を2回実行する必要がありました。なぜなら、「アップロード」を理解しておらず、バケットを1つしか作成しなかったからです。その後、2つのバケットで再度実行し、アップロードのチェックボックスを削除する必要がありました。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に移動することを推奨するように更新されるべきだと思います。そうすれば、ユーザーとS3の設定を構成する前に、ymlファイルだけでデータベースをコマンドラインで復元できます。
「いいね！」 1
何のことか分かりません。バックアップは機能しています。写真をご覧ください。
S3 を使用しているのは、DigitalOcean のバックアップが週に 1 回しかなく、サーバーがクラッシュして削除された場合、役に立たないからです。
その一方で、S3 またはダウンロードした S3 バケットからの復元は問題ないことを願っています。
画像をアップロードしておらず、S3 バックアップに画像（ごくわずかですが）が含まれていることを願っています。
一般的に：いいえ。
S3バケット内のイメージを別のS3バケットにバックアップすることにはあまり意味がありませんか？
「いいね！」 2
もっと曖昧さをなくしてもらえますか？
指示には2つのS3バケットがありましたが、うまくいきませんでした。
S3バケットは1つしかありません。バックアップに写真が含まれていることを願っています。これで正しいですか？
ローカルバックアップも同じように機能すると思いますよね？
私の質問について、すべて文章で答えてください。チュートリアルも非常にわかりにくかったです。
「いいね！」 1
「いいえ」の何が曖昧なのですか？（そして、「バックアップのバックアップ」の何が曖昧でないのですか？ ;)）
もう一度試してみましょう。
アップロードがS3に設定されている場合、アップロードはバックアップに含まれません。
「いいね！」 2
「アップロード」の代わりに「ピクチャ」という用語を使用しましょう。これは他のメディアも含む可能性がありますが、S3にアップロードしているテキストコンテンツと混同しないようにするためです。
では、このスレッドで説明されているようにS3にある62MBのバックアップファイルにはピクチャは含まれていないということですか？
どうすればこれらがバックアップに含まれるようにできますか？
ローカルバックアップにもピクチャは含まれていますか？
S3の「アップロード（メディアの）」を設定したとき、これも曖昧でしたが、誰もピクチャを投稿できませんでした。なぜならS3から拒否されていたからです。
ローカルとS3の両方で毎日のバックアップを行う方法はありますか？
ピクチャが5日間失われても構いません。私たちは主にテキストベースのグループです。
しかし、テキストが5日間失われたら困ります。Digital Oceanは有料ですが7日間のバックアップしか行いません。
そのため、毎日バックアップできても、ドロップレットがハッキングされたり破損したりした場合、それらのバックアップも失われてしまいます。S3にはあまり付加価値がないように思えてきました。
WordPressのように、GoogleドライブやDropboxアカウントにバックアップできるような簡単なバックアップがあればいいのですが。
いや、それは悪い考えだ。テキストファイルを添付ファイルとしてアップロードした場合もアップロードであり、混乱を招く。また、投稿内のテキストはデータベースに保存される。だから、「アップロード」という言葉にこだわり続ける。
アップロードがS3にある場合、バックアップには含まれない。その場合、バックアップにはデータベースのコピーのみが含まれる。バックアップがローカルであろうとS3であろうと関係ない。
アップロードがS3にない場合、バックアップに含まれる。その場合、バックアップにはデータベースのコピーとアップロードのコピーが含まれる。バックアップがローカルであろうとS3であろうと関係ない。
S3に何かを保存している場合、それがアップロードであろうとデータベースのバックアップであろうと、DOドロップレットがハッキングされたり破損したりしても失われることはない。だから、あなたの言っている意味がわからない。
あなたの投稿はファイルや画像のアップロードではなく、バックアップに関するものなので、これらを別のトピックに移動します。
「いいね！」 3
S3バックアップを自動的にGlacierに移動したいのですが、最初の投稿でリンクされている手順がよくわからず混乱しています。あまり説明されていないのは、古い情報が含まれているからかもしれません。
ここのどのオプションをチェックすればよいですか？ 
もう一度質問してもよろしいでしょうか。どなたかこれらの手順を実行して、この件についてご存知の方がいらっしゃいますか？
また、S3料金の変動の原因をご存知ですか？
さらに、フォーラム開設（2020年9月）以来、バックアップサイズは約15%増加しましたが、S3料金は2.50ドルから5ドルへと倍増しました。これほど高額になった理由をご存知ですか？
そのため、Glacierを使用したいと考えています。
編集：こちらで説明されている手順に従いました。これでどうなるか見てみます。
「いいね！」 1
さて、うまくいきませんでした。
私のライフサイクル設定：
私のS3バケット：
Glacierにバックアップはありません。
では…この自動化されたS3からGlacierへの移行を達成できた方々に2つの質問があります：
-
私の設定で何が間違っている可能性がありますか？
-
Glacierの最小ストレージ期間料金は90日です。これは、1日に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は、バケット名に小文字のアルファベット、数字、ダッシュのみを使用する必要があります。
- BackblazeのWeb UIで折り返さずにきれいに表示されるように、30文字以下にすることをお勧めします。
- この例では：
- プライベートバケット
- 暗号化を有効にする（SSE-B2）
- オブジェクトロックを有効にする
- 名前：
- アプリケーションキーを作成します（Backblaze > Account > App Keys）。
- keyName：
example-discourse - bucketName（バケットへのアクセスを許可）：
example-discourse-g87he56ht8vg - capabilities：read and write
- namePrefixとvalidDurationSecondsは空白のままにします。
- 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' # テストレストア中にメールを無効にするにはコメントを解除
## このコンテナYAML以降のデータなしで復元できます。
## 上記の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（バケットの設定に移動）：
- オブジェクトロック（デフォルトの保持ポリシー）：7日間
- ライフサイクル設定（カスタム）：
fileNamePrefix：default/example-com（オプション）daysFromUploadingToHiding：8日間- これはオブジェクトロック+1である必要があります
daysFromHidingToDeleting：1日
この例での保持期間を要約すると：
- Discourse：
- Discourseは1日ごとにバックアップを作成します。
- 各バックアップファイルは、B2へのアップロード後7日間不変です（オブジェクトロック）。これにより、事故やランサムウェアなどから保護されます。
- アップロードから8日後、バックアップのオブジェクトロックが期限切れになります。再び変更可能になるため、ライフサイクルルールでバックアップファイルを非表示にできます。
- ライフサイクルルールの次の部分で、非表示になってから1日後にファイルを削除します。
したがって、毎日バックアップを取得できます。保持期間は、バックアップが削除されない1週間です。その後、バックアップは2日後に削除されます。したがって、実際にはバックアップは約9日間存在します。
誰かの役に立つことを願っています 
改めて考えると、Discourseに保持期間を処理させる方が良いかもしれません（maximum_backups）。そうすれば、Discourseがダウンしている間にバックアップが自動的に期限切れになることはありません。復旧しようとしている間に時計が刻むのは避けたいでしょう。その方法を選択した場合、この例ではmaximum_backups=8とs3_disable_cleanup=falseを設定し、B2のライフサイクルポリシーを使用しないことができます。ただし、オブジェクトロックポリシー（7日間）は引き続き使用します。
編集：実際には、S2クライアントがファイルを削除した場合、ファイルは削除されるのではなく「非表示」になるだけなので、B2ライフサイクルポリシーは依然として必要だと思います。「Keep only the last version of the file」ポリシーを使用しており、これはdaysFromHidingToDeleting=1, daysFromUploadingToHiding=nullと同等です。
検討して、どちらのアプローチが適切か判断してください。
ところで、この投稿にはいくつかの行き来があることに気づきました。現状でも有益だと思いますが、もし誰かが望むなら、私の実際の推奨事項を含む、もう少し簡単な投稿を作成できます。
「いいね！」 6
これらを アップロード用の S3 互換オブジェクトストレージプロバイダーの設定 で説明されているように環境変数に入れると、yml ファイルだけでコマンドラインから新しいサーバーにサイトを復元できます。
残りは良い計画のようです。
「いいね！」 3
discourse restore <backup.tar.gz>
環境変数が設定されていれば、バケット内を検索しますか？もしそうなら、かなりクールです。
その場合、コンテナのymlに秘密を保持したくない理由がある場合、bashでexportを使用して手動で設定することもできるでしょう。
「いいね！」 1
確認のためですが、S3 バックアップに移行して正常に動作することを確認した後、そのフォルダーの内容を安全に削除して使用済みスペースを解放できますか？