Configurer les sauvegardes automatiques pour Discourse

[Discourse]

Ce guide explique comment configurer les sauvegardes automatiques pour Discourse, y compris les options de stockage sur des serveurs locaux et des stockages compatibles S3.

Apprenez à configurer les sauvegardes automatiques pour votre plateforme Discourse.

Ce guide couvre la configuration des sauvegardes automatiques, leur stockage sur des serveurs locaux ou des stockages compatibles S3, et la gestion des options de rétention de stockage comme Amazon Glacier.

Configuration des sauvegardes automatiques

1. Accédez aux paramètres /admin.
2. Sélectionnez la section Backup (Sauvegarde).
3. Définissez backup_frequency sur l’intervalle souhaité en jours. La valeur par défaut est 7 (hebdomadaire). Définissez sur 1 pour des sauvegardes quotidiennes, ou 0 pour désactiver les sauvegardes automatiques. La valeur maximale est 30.

backup_frequency100%75%50%

Paramètres de sauvegarde supplémentaires

• backup_time_of_day — l’heure de la journée (UTC) à laquelle les sauvegardes s’exécutent. Défaut : 3:30.
• backup_with_uploads — inclure les téléchargements dans les sauvegardes planifiées. Défaut : activé. La désactivation de cette option ne sauvegardera que la base de données.
• maximum_backups — le nombre maximal de sauvegardes à conserver. Les sauvegardes plus anciennes sont automatiquement supprimées. Défaut : 5.
• remove_older_backups — supprimer les sauvegardes plus anciennes que le nombre de jours spécifié. Laisser vide pour désactiver.

Stocker les sauvegardes sur le serveur local

Par défaut, les sauvegardes sont stockées sur votre serveur local. Pour les instances auto-hébergées, vous y accédez à /var/discourse/shared/standalone/backups/default.

Stocker les sauvegardes sur un stockage compatible S3

Utilisation du panneau d’administration

1. Créez un compartiment S3 (bucket).
2. Définissez s3_backup_bucket dans le panneau d’administration.

• Suivez les étapes dans configurer les téléchargements de fichiers et d’images vers S3.

3. Configurez s3_access_key_id, s3_secret_access_key, et s3_region.
4. Définissez backup_location sur “S3”.

ATTENTION

Stocker les sauvegardes et les téléchargements normaux dans le même compartiment et le même dossier n’est plus pris en charge et ne fonctionnera pas.

Le chemin s3_backup_bucket doit être utilisé uniquement pour les sauvegardes. Si vous devez utiliser un compartiment contenant d’autres fichiers, assurez-vous de fournir un préfixe lorsque vous configurez le paramètre s3_backup_bucket (exemple : my-awesome-bucket/backups) et assurez-vous que les fichiers avec ce préfixe sont privés.

Désormais, toutes les sauvegardes seront téléchargées vers S3 et ne seront plus stockées localement. Le stockage local ne sera utilisé que pour les fichiers temporaires pendant les sauvegardes et les restaurations.

Accédez à l’onglet Backups (Sauvegardes) dans le tableau de bord d’administration pour parcourir les sauvegardes – vous pouvez les télécharger à tout moment pour effectuer une sauvegarde manuelle hors site.

Utilisation des variables d’environnement dans app.yml

Vous pouvez également configurer les sauvegardes S3 à l’aide de variables d’environnement dans app.yml. Pour plus d’informations, consultez Configurer un fournisseur de stockage objet compatible S3 pour les téléchargements.

Notez que l’article ci-dessus couvre la configuration S3 via app.yml pour les sauvegardes et pour les téléchargements de fichiers/images. Si vous souhaitez uniquement utiliser S3 pour les sauvegardes (et non pour les téléchargements de fichiers/images), vous pouvez omettre les paramètres suivants de votre configuration app.yml :

• DISCOURSE_USE_S3
• DISCOURSE_S3_CDN_URL
• DISCOURSE_S3_BUCKET

Vous n’avez pas non plus besoin de configurer l’étape after_assets_precompile dans ce cas, ni de configurer un CDN.

Assurez-vous d’inclure tous les autres paramètres requis pour votre fournisseur de stockage, comme mentionné dans l’article. Voici un exemple de configuration qui n’active S3 que pour les sauvegardes (pour Scaleway S3) :

DISCOURSE_S3_REGION: nl-ams
DISCOURSE_S3_ENDPOINT: https://s3.nl-ams.scw.cloud
DISCOURSE_S3_ACCESS_KEY_ID: my_access_key
DISCOURSE_S3_SECRET_ACCESS_KEY: my_secret_access_key
DISCOURSE_S3_BACKUP_BUCKET: my_bucket/my_folder
DISCOURSE_BACKUP_LOCATION: s3

Archivage vers un stockage à coût réduit

Notez que sur AWS S3, vous pouvez également activer une règle de cycle de vie de déplacement automatique vers un compartiment Glacier pour maintenir vos coûts de sauvegarde S3 bas. D’autres fournisseurs de stockage ont souvent une offre similaire.

[olivermark83 (Oliver Mark)]

You are able to Archive Backups from your S3 Bucket to Glacier.
It is cheaper, but an Restore attemps more Time.

This Site will Help you to reduce Backup costs.:

Archiving Amazon S3 Data to Amazon Glacier | Amazon Web Services

[Frez (FOSS dev/hacker)]

@codinghorror

Note that you can also enable an automatic move to Glacier bucket lifecycle rule to keep your S3 backup costs low.

Setting this up can be rather confusing. Here’s a simple guide to help you out.

• Log into your Discourse admin panel
• Configure daily backups
• Set maximum backups to 7
• Log into your Amazon Web Services account
• Go in the S3 Dashboard
• Open the bucket containing the backups
• Click on the properties tab
• Activate versioning
• Open the Lifecycle menu
• Add a rule for the whole bucket
• Set current version to expire after 15 days
• Set previous version to
• Archive to Glacier after 1 days
• expire after 91 days
• Save and logout

How it works

Versioning will keep backups automaticly deleted by Discourse. One day after beeing deleted it will be moved to the Glacier storage. After 91 days it will be delete from the Glacier storage.

Warning

Amazon charge you for item stored in Glacier for 90 days even if you delete them before. Make sure your Glacier Lyfecicle keep your file at least 90 days.

[MarcP]

I may have missed this, but how to I make sure a bucket for backups is private the proper way? Setting up file and image uploads to S3 doesn’t seem to be described here.

[Alex_P]

@Frez

Set current version to expire after 15 days

Looks like there is no such option anymore.

UPD: ah, now it’s split into 2 steps of this wizard.

So I guess it should be like this:

[jorymorrison]

Does S3 backup functionality play nice without IAM access key and secret if using AWS roles assigned to the instance and s3 use iam profile is enabled in the settings menu?

Edit: The answer is YES! Just ensure you have region set appropriately.

[nathank (Nathan Kershaw)]

@misterjtc

Je suis un peu confus quant à l’utilisation de ce guide pour configurer les sauvegardes également.

J’ai fait ce qui me semblait logique, mais je me suis un peu perdu en cours de route et maintenant j’obtiens « Échec de l’accès au stockage de sauvegarde : Accès refusé ».

J’ai eu ce problème moi aussi, qui a été résolu en ajoutant quelques lignes au document de stratégie :

"Resource": [
        "arn:aws:s3:::your-uploads-bucket",
        "arn:aws:s3:::your-uploads-bucket/*",
        "arn:aws:s3:::your-backups-bucket",
        "arn:aws:s3:::your-backups-bucket/*"
      ]

Cela devrait-il être ajouté à l’OP (qui n’est pas un wiki) ? Ou peut-être dans l’OP de Set up file and image uploads to S3 ?

[pfaffman (Jay Pfaffman)]

@codinghorror

Alors, vous souhaitez sauvegarder automatiquement toutes vos données Discourse chaque jour ?

Y a-t-il une bonne raison pour laquelle les sauvegardes quotidiennes ne sont pas définies par défaut ?

Corrections nécessaires pour l’OP

Ajouter quelque chose concernant le déplacement des sauvegardes S3 vers Glacier ?
Supprimer le contenu sur S3 et ajouter un lien vers Configure an S3 compatible object storage provider for uploads

[codinghorror (Jeff Atwood)]

@pfaffman

Y a-t-il une bonne raison pour laquelle les sauvegardes quotidiennes ne sont pas activées par défaut ?

Cela serait excessif et coûteux. Pour la même raison que nous ne recommandons pas de changer l’huile de votre voiture tous les 800 kilomètres ?

[pfaffman (Jay Pfaffman)]

@codinghorror

Cela serait excessif et coûteux.

Vous sauvegardez vos serveurs une fois par semaine ?

Je pense que votre analogie de la vidange tous les 500 milles serait une bonne réponse pour expliquer « pourquoi ne pas conserver 30 sauvegardes ? », mais cela ne me semble pas pertinent ici.

Ne pensez-vous pas que, si vous prévoyez d’avoir 5 sauvegardes, la plupart des gens préféreraient des sauvegardes quotidiennes, afin que, s’ils doivent revenir à une sauvegarde, ils ne perdent pas plus d’une journée ? La seule fois où je me souviens qu’une ancienne sauvegarde ait été utile, c’était lorsque des images sont sorties de tombstone.

Si elles ont si peu d’espace disque qu’elles ne peuvent pas conserver 5 sauvegardes, il vaudrait mieux l’apprendre dans 5 jours, alors qu’elles ont encore le souvenir de ce qu’elles ont fait, plutôt que d’attendre 4 à 5 semaines.

[codinghorror (Jeff Atwood)]

@pfaffman

Vous sauvegardez vos serveurs une fois par semaine ?

Oui, c’est exact, pour mes serveurs auto-hébergés.

Si vous préférez d’autres paramètres, n’hésitez pas à les modifier par rapport aux valeurs par défaut. Qu’est-ce qui vous en empêche ?

[pfaffman (Jay Pfaffman)]

@codinghorror

Oui, c’est exact, pour mes serveurs auto-hébergés.

Eh bien, je vous jure !

@codinghorror

Qu’est-ce qui vous en empêche ?

Je fais le ménage dans des sujets comme celui-ci. Si les paramètres par défaut avaient été modifiés, cela ne serait pas nécessaire !

Je suis convaincu que les paramètres par défaut ne seront pas modifiés, donc je vais avancer. :wink

[codinghorror (Jeff Atwood)]

Une fois par semaine est un bon point de départ et une valeur par défaut solide.

[Discoursecurious]

@nathank

@misterjtc

Je suis un peu perdu quant à l’utilisation de ce guide pour configurer les sauvegardes également.

J’ai fait ce qui me semblait logique, mais je me suis un peu perdu en cours de route et maintenant j’obtiens « Échec de l’accès au stockage de sauvegarde : Accès refusé »

J’ai eu ce problème aussi, qui a été résolu en ajoutant quelques lignes au document de stratégie :

"Resource": [
        "arn:aws:s3:::your-uploads-bucket",
        "arn:aws:s3:::your-uploads-bucket/*",
        "arn:aws:s3:::your-backups-bucket",
        "arn:aws:s3:::your-backups-bucket/*"
      ]

Cela devrait-il être ajouté au premier message (qui n’est pas un wiki) ? Ou peut-être dans le premier message de Configuration des téléchargements de fichiers et d’images vers S3 ?

J’ai eu exactement le même problème !

Je suggère d’ajouter une note à ce sujet dans le premier message également !

[jessicah (Jessica Hamilton)]

Ce serait bien si cela pouvait être utilisé pour télécharger vers un autre fournisseur compatible S3, comme MinIO en cours d’exécution.

[pfaffman (Jay Pfaffman)]

Si vous souhaitez utiliser MinIO, consultez Utiliser un stockage objet pour les uploads (S3 et clones). Si vous souhaitez des services distincts pour les sauvegardes et les ressources, vous êtes mal barré (bien qu’il existe des moyens de configurer des déclencheurs pour copier d’un bac vers un autre).

[jessicah (Jessica Hamilton)]

Non, juste pour les sauvegardes, afin qu’elles soient automatiquement transférées vers une autre machine sur mon réseau.

[pfaffman (Jay Pfaffman)]

Alors, le guide que j’ai lié est ce que vous cherchez.

[Tris20 (Tristan)]

Est-il possible d’être plus fréquent qu’une fois par jour ? Je préfère ne pas faire de suppositions et définir la fréquence de sauvegarde avec un nombre à virgule flottante.

[pfaffman (Jay Pfaffman)]

Si vous souhaitez des sauvegardes plus fréquentes, vous devrez les effectuer en externe.