Problème avec les sauvegardes multisites sur S3--sauvegardes stockées à la racine

Installation
1

J’ai une instance multisite sur une AWS EC2. J’ai configuré les sauvegardes comme suit :

DISCOURSE_S3_BACKUP_BUCKET: lc-sitename
DISCOURSE_S3_SECRET_ACCESS_KEY: secret-key
DISCOURSE_S3_ACCESS_KEY_ID: key-id
DISCOURSE_BACKUP_LOCATION: s3

Les sauvegardes pour les instances multisites sont stockées à la racine du bucket, mais n’apparaissent pas dans la liste de l’interface utilisateur. Les sauvegardes pour le site principal sont stockées sous default comme prévu. Cela signifie que les sauvegardes sont invisibles pour la restauration et ne sont pas élaguées conformément aux paramètres.

La section multisite ressemble à ceci :

        site:
           adapter: postgresql
           database: site
           pool: 25
           timeout: 5000
           host: data
           password: secret
           host_names:
             - community.site.org

Est-il possible que si DISCOURE_USE_S3 n’est pas défini, les sauvegardes se retrouvent au mauvais endroit ? (J’ai essayé de définir use_s3 dans discourse.conf, mais sans redémarrer unicorn, j’ai plutôt exécuté une sauvegarde en ligne de commande et elle a toujours été placée à la racine, pas au nom du sous-site).

Il y a eu un problème avec les téléchargements sur S3 (mauvaise configuration du bucket, peut-être), donc S3 est uniquement pour les sauvegardes.

1 « J'aime »
2

J’y ai passé encore une heure et demie.

L’un des sites multisites place correctement ses téléchargements sauvegardes dans le bon répertoire, mais deux ne le font pas.

Ceux qui ne vont pas au bon endroit avaient des bases de données restaurées à partir d’une instance à site unique, donc je suppose qu’il y a quelque chose dans la base de données qui force la sauvegarde à aller à la racine du dossier de sauvegarde plutôt qu’au nom du site (ou par défaut pour le site par défaut).

@gerhard désolé de vous déranger, mais pourriez-vous jeter un coup d’œil rapide pour voir s’il y a quelque chose d’évidemment idiot que je néglige ?

3

Oui, le stockage des téléchargements est par conception, si une sauvegarde provient d’une instance de site unique, elle est restaurée différemment.

      was_multisite = BackupMetadata.value_for("multisite") == "t"
      upload_path = "/#{Discourse.store.upload_path}/"
      uploads_folder = was_multisite ? "/" : upload_path

Mais ne s’agissait-il pas de l’endroit où les sauvegardes étaient placées, et non de l’endroit où les images sont restaurées ?

1 « J'aime »
4

Oui.

C’est exact.

Mais oops :

Comme je l’ai dit (correctement) plus tôt, cette instance utilise (actuellement ?) S3 uniquement pour les sauvegardes et non pour les téléversements.

Ce sont les sauvegardes de 2 des 3 sous-sites qui sont placées à la racine du bucket de sauvegarde. Le site principal les pousse vers default comme prévu, et un des instances multisites les pousse vers le répertoire sitename.

1 « J'aime »
5

Hmm, c’est un comportement étrange. Parlez-vous des sauvegardes téléchargées depuis le navigateur ou des sauvegardes créées par le système ?

Je ne vois pas de raison pour que les sauvegardes créées par le système se retrouvent au mauvais endroit. Le code semble assez simple.

s3_helper est configuré avec le bon bucket et le nom multisite.

6

Je veux dire que la création d’une sauvegarde à partir de l’interface Web ou de la tâche Rake pour deux des 3 hôtes multisites (qui ont tous deux été migrés depuis un autre serveur) télécharge la sauvegarde à la racine du compartiment S3 de sauvegarde plutôt que dans nom_du_site/nom_de_la_sauvegarde.

Cela me semble étrange aussi.

J’essaierai d’ajouter quelques puts à ces fonctions pour voir si je peux le retracer.

Je pense que j’ai fait puts pour le source_path et qu’il avait le chemin complet correct dans le système d’exploitation, mais lorsqu’il est téléchargé sur S3, le nom du site n’est plus dans le chemin.

J’examinerai plus attentivement la semaine prochaine. Les sauvegardes sont là, elles ne sont juste pas là où Discourse les trouvera.