Thanks for the hint. That pushed me towards the command line option which we can schedule to do whenever: 
2 « J'aime »
J’ai réussi à faire fonctionner cela, mais il semble que la case de téléchargement n’était pas vraiment nécessaire, et je n’en comprends pas non plus l’utilité. Quel est son but ? La seule chose que je veux, ce sont des sauvegardes sur S3 au lieu du local pour mon serveur. Le serveur n’a que des sauvegardes automatiques hebdomadaires…
Le Json avait aussi des problèmes… J’ai réussi à le faire fonctionner en utilisant une référence d’un autre site. Cependant, personne ne pouvait télécharger d’images car j’avais coché la case de téléchargement (comme décrit ici)… Désactiver cette case a résolu le problème de téléchargement d’images pour les utilisateurs et leurs photos de profil.
Quel est le but du téléchargement d’images ? J’espère sincèrement que les images sont incluses dans les sauvegardes S3.
J’ai dû suivre les instructions deux fois car je ne comprenais pas “téléchargements” et n’avais créé qu’un seul bucket. Ensuite, j’ai dû recommencer avec 2 buckets, puis j’ai dû décocher la case pour les téléchargements. Il serait peut-être utile d’avoir un sujet séparé, plus simple, pour les sauvegardes S3… et uniquement les sauvegardes.
{
"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 « J'aime »
Bien que je pense que ce sujet devrait être mis à jour pour recommander que la configuration S3 soit déplacée vers app.yml plutôt que vers la base de données, de cette façon, vous pouvez restaurer la base de données en ligne de commande avec uniquement le fichier yml et sans avoir à la configurer avec un utilisateur et une configuration s3 avant de faire une restauration.
1 « J'aime »
Je ne suis pas sûr de ce dont vous parlez. Mes sauvegardes fonctionnent, voyez l’image.
J’utilise S3 car les sauvegardes de Digital Ocean ne sont que hebdomadaires, et si le serveur plante et est supprimé, cela n’est pas utile.
D’un autre côté, j’espère que la restauration à partir de S3 ou d’un compartiment S3 téléchargé se passera bien.
Je ne télécharge pas les images, et j’espère que les sauvegardes S3 sont sauvegardées, y compris les images (bien que très peu nombreuses).
En général : non.
Cela n’a pas beaucoup de sens de sauvegarder des images d’un bucket S3 dans un autre bucket S3 ?
2 « J'aime »
Pouvez-vous être moins ambigu ?
Les instructions contenaient 2 buckets S3. Je n’ai pas réussi à faire fonctionner cela.
Je n’ai qu’un seul bucket S3. J’espère que les images sont incluses dans cette sauvegarde… est-ce correct ?
J’imagine que les sauvegardes locales fonctionnent de la même manière, n’est-ce pas ?
Veuillez répondre par des phrases complètes concernant mes questions. Le tutoriel était également très confus.
1 « J'aime »
Qu’y a-t-il d’ambigu dans « non » ? (Et qu’y a-t-il de non ambigu dans « les sauvegardes sauvegardées » 
)
Je vais réessayer.
Si vous avez configuré les téléchargements sur S3, alors les téléchargements ne sont pas inclus dans votre sauvegarde.
2 « J'aime »
Utilisons le terme « images » au lieu de « téléchargements », même si cela peut concerner d’autres médias.
Ainsi, nous ne confondrons pas le contenu textuel avec un téléchargement que j’envoie vers s3.
Donc, les 62 Mo de fichiers de sauvegarde sur s3, tels qu’illustrés et téléchargés dans ce fil, n’incluent pas les images ?
Alors, comment puis-je m’assurer que les sauvegardes contiennent ces éléments ?
Les sauvegardes locales contiennent-elles aussi les images ?
Lorsque j’ai configuré s3 pour les « téléchargements (de médias) », ce qui était également ambigu. Personne ne pouvait publier d’images car elles étaient rejetées par s3…
Existe-t-il un moyen d’avoir des sauvegardes quotidiennes locales et sur s3 ?
Je me soucie peu si 5 jours d’images sont perdus, nous sommes principalement un groupe basé sur le texte.
Mais je me soucierais si 5 jours de texte étaient perdus. Digital Ocean ne fait que des sauvegardes sur 7 jours si vous les payez.
Donc, même si je peux sauvegarder quotidiennement, si le droplet est piraté ou endommagé, nous perdons ces sauvegardes… Je commence à penser qu’il n’y a pas beaucoup de valeur ajoutée dans s3.
J’aimerais qu’il y ait des sauvegardes simples similaires à WordPress, qui me permettent de sauvegarder sur mon compte Google ou Dropbox.
Non, c’est une mauvaise idée. Si vous téléchargez un fichier texte en tant que pièce jointe, c’est aussi un téléchargement, cela prêtera à confusion. Et le texte d’une publication est stocké dans la base de données. Je m’en tiens donc au terme téléchargements.
Si vos téléchargements sont sur S3, ils ne sont pas inclus dans les sauvegardes. Dans ce cas, les sauvegardes ne contiennent qu’une copie de la base de données. Peu importe que vos sauvegardes soient locales ou sur S3.
Si vos téléchargements ne sont pas sur S3, ils sont inclus dans les sauvegardes. Dans ce cas, les sauvegardes contiennent une copie de la base de données et une copie des téléchargements. Peu importe que vos sauvegardes soient locales ou sur S3.
Si vous stockez quelque chose sur S3, qu’il s’agisse de téléchargements ou de sauvegardes de la base de données, ils ne seront pas perdus si votre goutte DO est piratée ou endommagée. Je ne vois donc pas votre point.
Étant donné que vos publications portent sur les sauvegardes et non sur les téléchargements de fichiers et d’images, je les déplace vers un autre sujet.
3 « J'aime »
Je voudrais déplacer automatiquement mes sauvegardes S3 vers Glacier mais je suis confus par les étapes liées dans le premier post, qui n’explique pas grand-chose, peut-être parce qu’il y a des choses obsolètes.
Quelles options doivent être cochées ici ? 
Puis-je reposer la question au cas où quelqu’un aurait suivi ces étapes et en saurait quelque chose ?
De plus, savez-vous ce qui cause ces fluctuations dans les frais S3 ?
De plus, depuis le lancement du forum (septembre 2020), la taille des sauvegardes a augmenté d’environ 15 %, mais les factures S3 ont doublé, passant de 2,50 à 5 . Avez-vous une idée pourquoi autant ?
C’est pourquoi j’aimerais utiliser Glacier.
Edit : J’ai suivi les étapes décrites ici et je verrai comment cela se passe.
1 « J'aime »
Bon, ça ne se passe pas. 
Ma configuration de cycle de vie :
Mon bucket S3 :
Aucune sauvegarde n’est sur Glacier.
Alors… Deux questions pour ceux qui ont réussi cette transition automatisée S3 vers Glacier :
-
Qu’est-ce qui pourrait clocher dans ma configuration ?
-
Les frais de durée de stockage minimum sur Glacier sont de 90 jours. Cela signifie-t-il que si je fais 1 sauvegarde par jour, je finirai par être facturé pour 90 sauvegardes sur Glacier chaque mois ?
Si c’est le cas, alors cette solution Glacier ne sera pas une bonne idée, à moins que je ne réduise considérablement ma fréquence de sauvegarde.
1 « J'aime »
Où sont stockées les sauvegardes dans le VPS ?
1 « J'aime »
J’ai ajouté ceci à l’OP :
2 « J'aime »
Pouvons-nous choisir le dossier des sauvegardes ou existe-t-il une solution de contournement sans codage ?
J’utilise un stockage de données de mon fournisseur d’hébergement pour pouvoir le monter et l’utiliser comme un disque local, mais il n’est pas censé être enregistré dans le chemin par défaut.
1 « J'aime »
Si vous souhaitez qu’il soit enregistré ailleurs, vous devrez modifier cela dans votre app.yml.
2 « J'aime »
Sauvegardes automatiques sur Backblaze B2
Voici comment je l’ai configuré pour un site hypothétique hébergé sur example.com
- Créez un compte sur Backblaze (pour l’instant, pas besoin d’entrer de paiement pour moins de 10 Go, c’est gratuit)
- Créez un bucket (Backblaze > Stockage Cloud B2)
- Nom :
$sitename-discourse-$randomcomplété à 30 caractères- Dans cet exemple :
example-discourse-g87he56ht8vg - Discourse a besoin que le nom du bucket ne contienne que des lettres minuscules, des chiffres et des tirets
- Je suggère de le garder à 30 caractères ou moins car cela s’affiche bien dans l’interface web de Backblaze sans retour à la ligne
- Dans cet exemple :
- Bucket privé
- Activez le chiffrement (SSE-B2)
- Activez le verrouillage d’objet
- Nom :
- Créez une clé d’application (Backblaze > Compte > Clés d’application)
- Nom de clé :
example-discourse - Nom du bucket (Autoriser l’accès au(x) bucket(s)) :
example-discourse-g87he56ht8vg - Capacités : lecture et écriture
- Laissez
keyNameetvalidDurationSecondsvides
- Nom de clé :
- Configurez les paramètres B2 de Discourse (Discourse > Admin > Paramètres)
backup_location:s3s3_backup_bucket:example-discourse-g87he56ht8vgs3_endpoint: ceci est affiché sur la page du bucket – assurez-vous de le préfixer avechttps://s3_access_key_id: (de l’étape précédente)s3_secret_access_key: (de l’étape précédente)- Backblaze ne vous montre la clé qu’une seule fois (lors de sa création) !
- D’ailleurs, vous pouvez aussi les définir comme variables d’environnement dans votre fichier
ymlde conteneur à la place. Cela vous permettrait de restaurer avec seulement ce fichier et rien d’autre :
env:
## Sauvegardes Backblaze B2
# DISCOURSE_BACKUP_LOCATION: 's3' # décommentez pour récupérer depuis la 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' # décommentez pour désactiver les e-mails pendant un test de restauration
## vous pouvez restaurer sans aucune donnée au-delà de ce fichier yml de conteneur.
## décommentez DISCOURSE_BACKUP_LOCATION ci-dessus, construisez le conteneur (./launcher rebuild ...),
## puis exécutez ceci à l'intérieur du conteneur (cela restaurera depuis le bucket B2) :
## discourse enable_restore
## discourse restore <example-com-...tar.gz> # choisissez le nom du fichier de restauration en parcourant l'interface web B2
## n'oubliez pas de désactiver la restauration par la suite
- Configurez la rétention des sauvegardes
- Discourse :
backup_frequency: 1 (sauvegardes quotidiennes dans cet exemple, mais vous pourriez faire des sauvegardes hebdomadaires)maximum_backups: ignorez ce paramètre – laissez Backblaze s’en charger
s3_disable_cleanup: true (Empêche la suppression des anciennes sauvegardes de S3 lorsqu’il y a plus de sauvegardes que le maximum autorisé)
- Backblaze (allez dans les paramètres de votre bucket) :
- Verrouillage d’objet (Politique de rétention par défaut) : 7 jours
- Paramètres du cycle de vie (personnalisé) :
fileNamePrefix:default/example-com(facultatif)daysFromUploadingToHiding: 8 jours- ceci doit être le verrouillage d’objet + 1
daysFromHidingToDeleting: 1 jour
en résumé la rétention dans cet exemple :
- Discourse :
- Discourse crée des sauvegardes tous les 1 jour
- Chaque fichier de sauvegarde est immuable pendant 7 jours après son téléchargement sur B2 (verrouillage d’objet). Cela vous protège contre les accidents, les ransomwares, etc.
- 8 jours après le téléchargement, le verrouillage d’objet sur la sauvegarde expire. Comme il est à nouveau modifiable, une règle de cycle de vie peut masquer le fichier de sauvegarde
- La partie suivante de la règle du cycle de vie supprime tout fichier 1 jour après qu’il ait été masqué
Vous obtenez donc des sauvegardes quotidiennes. La période de rétention est d’une semaine pendant laquelle les sauvegardes ne peuvent être supprimées quoi qu’il arrive. Ensuite, les sauvegardes sont supprimées 2 jours plus tard. Donc, en réalité, une sauvegarde dure environ 9 jours.
J’espère que cela aidera quelqu’un 
En y repensant, il est peut-être préférable de laisser Discourse gérer la rétention (maximum_backups). De cette façon, vos sauvegardes n’expireront pas automatiquement si Discourse est en panne. Vous ne voudriez pas qu’une horloge tourne sur elles pendant que vous essayez de récupérer. Si vous choisissez cette voie, vous pourriez définir maximum_backups=8 et s3_disable_cleanup=false dans cet exemple et ne pas utiliser de politique de cycle de vie dans B2. Vous utiliseriez toujours la politique de verrouillage d’objet (7 jours), cependant.
edit : en fait, je pense que vous avez toujours besoin d’une politique de cycle de vie B2 car je pense que les fichiers ne sont que “masqués” et non supprimés lorsque le client S2 les supprime. J’utilise la politique “Conserver uniquement la dernière version du fichier”, qui équivaut à daysFromHidingToDeleting=1, daysFromUploadingToHiding=null.
Je suppose qu’il faut y réfléchir et décider quelle approche vous convient le mieux.
D’ailleurs, je réalise qu’il y a des allers-retours dans ce post. Je pense que c’est informatif tel quel, mais si quelqu’un le souhaite, je pourrais faire un autre post un peu plus simple avec mes recommandations réelles.
6 « J'aime »
Si vous les placez dans des variables d’environnement comme décrit dans Configurer un fournisseur de stockage d’objets compatible S3 pour les téléchargements, vous pourrez restaurer votre site sur un nouveau serveur à partir de la ligne de commande avec uniquement votre fichier yml.
Le reste semble être un bon plan.
3 « J'aime »
discourse restore <backup.tar.gz>
cela cherchera dans votre bucket si vous avez défini les variables d’environnement ? plutôt cool si c’est le cas.
et dans ce cas, vous pourriez probablement aussi les définir manuellement avec export dans bash dans le cas peu probable où vous devriez récupérer. c’est-à-dire si vous ne voulez pas conserver de secrets dans votre yml de conteneur pour une raison quelconque.
1 « J'aime »
Juste pour confirmation, une fois que j’aurai migré vers les sauvegardes S3 et testé qu’elles fonctionnent, puis-je supprimer en toute sécurité le contenu de ce dossier pour récupérer de l’espace utilisé ?