Configure automatic backups for Discourse

Documentation Auto-hébergement
,
131

Sauvegardes automatiques sur Backblaze B2

Voici comment je l’ai configuré pour un site hypothétique hébergé sur example.com

  1. Créez un compte sur Backblaze (pour l’instant, pas besoin d’entrer de paiement pour moins de 10 Go, c’est gratuit)
  2. Créez un bucket (Backblaze > Stockage Cloud B2)
    • Nom : $sitename-discourse-$random complé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
    • Bucket privé
    • Activez le chiffrement (SSE-B2)
    • Activez le verrouillage d’objet
  3. 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 keyName et validDurationSeconds vides
  4. Configurez les paramètres B2 de Discourse (Discourse > Admin > Paramètres)
    • backup_location : s3
    • s3_backup_bucket : example-discourse-g87he56ht8vg
    • s3_endpoint : ceci est affiché sur la page du bucket – assurez-vous de le préfixer avec https://
    • 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 yml de 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
  1. 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 :sunglasses:
      • 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 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 :slight_smile:

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 »