Salut tout le monde - en train d’essayer de migrer de Discourse hébergé vers l’auto-hébergement. J’ai effectué un certain nombre de tests réussis sur diverses choses, mais lorsque j’essaie de faire la vraie migration, y compris tous les téléchargements, après quelques heures de décompression de l’archive, il indique qu’aucun fichier ou répertoire de ce type n’existe lors de la tentative d’extraction du fichier de vidage. Je suis donc confronté à la perspective de perdre environ 140 Go de téléchargements, à moins que quelqu’un n’ait des idées ?
Pouvez-vous fournir le journal ?
Restaurez-vous à partir de la ligne de commande ou de l’interface Web ? Je recommande l’interface Web.
Bonjour - J’ai joint le journal à l’e-mail précédent, bien que je le joigne à nouveau ici. Je l’ai d’abord essayé en utilisant l’interface Web, puis une deuxième fois via la ligne de commande. Je soupçonne que la sauvegarde pourrait être corrompue d’une manière ou d’une autre, car elle n’est pas reconnue lorsqu’elle est téléchargée sur S3 et est rejetée presque instantanément si j’essaie de la télécharger via le navigateur.
restore-failure-log.txt (3,28 Ko)
C’est ce qu’il semble. Avez-vous téléchargé avec le navigateur Web ou avec scp/rsync ? Je recommanderais de télécharger à nouveau avec rsync.
Salut Jay - désolé, j’ai été un peu confus tout à l’heure car nous avons également eu des discussions avec Discourse par e-mail tout au long de ce processus de migration, et c’est là que j’ai joint le fichier journal.
En regardant l’erreur, je soupçonne que le tarball ne contient pas réellement de dump sql, juste des images. Le fichier a été initié et vérifié par Discourse en notre nom. Je l’ai téléchargé via http et téléversé sur le serveur via scp, car le téléversement par navigateur l’a rejeté.
Oui, je viens d’exécuter une commande pour inspecter le contenu du tarball et il ne contient que des images, pas de dump SQL.
Pouvez-vous vérifier si les tailles des archives tar sont exactement les mêmes ?
- sur l’instance CDCK
- celle téléchargée
- celle que vous avez téléchargée en utilisant scp
Vous pourriez vouloir utiliser tar tfvz pour vérifier si l’archive n’est pas tronquée.
Vous pourriez vouloir vérifier si vous ne manquez pas d’espace disque quelque part, car cela nécessite plusieurs fois la taille de l’archive.
Ok, je suis sorti un peu mais je vérifierai plus tard. L’espace ne devrait pas poser de problème car j’ai 512 Go et le fichier de sauvegarde fait 70 Go. J’ai été surpris que le fichier soit quelques Go plus petit que le dernier que nous avons créé, je m’attendais à ce qu’il soit légèrement plus grand. Je suis à peu près sûr que pour une raison quelconque, il n’a pas inclus la sauvegarde SQL, ce qui expliquerait la différence de taille.
Salut @pfaffman @RGJ, juste une mise à jour sur la façon dont cela a progressé. Le dump SQL était effectivement manquant dans l’archive téléchargée, et je n’étais pas sûr si prendre une sauvegarde de base de données séparée et l’insérer dans l’archive fonctionnerait (et cela prendrait plusieurs heures à tester). Nous avons donc fini par restaurer la base de données et migrer (avec succès).
Le problème maintenant est que dès que Discourse décommissionnera tout et fermera le bucket S3 / CDN, toutes nos images historiques seront rompues.
J’ai toutes les images, et je pense que je peux tout télécharger dans notre bucket S3 en conservant la même structure de dossiers. J’ai vu quelques fils de discussion discutant de la possibilité d’utiliser discourse.remap / dbhelper.remap pour mettre à jour en masse les liens au niveau de la base de données. Vos réflexions à ce sujet sont très appréciées !
Je n’arrive pas à imaginer comment cela a pu se produire. Votre navigateur a-t-il d’une manière ou d’une autre décompressé et désarchivé la sauvegarde et vous avez essayé de la reconstituer ?
Vous pouvez demander aux gens de discourse.org de vous donner une sauvegarde qui inclut les téléchargements. C’est ce que vous voulez faire. Ils activent un include_s3_uploads_in_backup (c’est proche, mais presque certainement pas le nom du paramètre caché).
Vous pouvez également utiliser des outils S3 pour les télécharger tous depuis leur bucket et les renvoyer. Il y a quelques sujets à ce sujet. Je ne le recommande pas.
J’ai récemment migré une sauvegarde d’environ 100 Go de CDCK vers Digital Ocean, une instance, un bucket spaces et des CDN bunny.net pour 1000 $. J’en étais désolé.
Est-ce juste la base de données ?
Oh, avez-vous d’une manière ou d’une autre effectué une restauration de la base de données uniquement, même si vous avez les images dans le fichier tar ?
Vous devez effectuer la restauration du fichier exact qu’ils ont créé et laisser Discourse le restaurer. Celui qui contient la base de données et les téléchargements. Ou vous pouvez examiner le code de restauration et concevoir pour faire manuellement ce qu’il fait pour remapper les images vers le nouvel emplacement. Bien que je pense que Richard ait les compétences et les outils pour le faire, je ne pense pas que vous vouliez le faire de cette façon.
Nous avons fait un essai il y a quelques mois et tout s’est bien passé. Je pense qu’ils ont laissé ce paramètre caché activé, car cette fois-ci, j’ai pu déclencher une sauvegarde incluant les téléchargements depuis le back-end, bien qu’après environ 12 heures, nous ayons reçu une notification indiquant qu’elle avait échoué. J’ai ensuite contacté Discourse et ils ont dit qu’ils créeraient la sauvegarde de leur côté. Quelques heures plus tard, la sauvegarde que j’avais initiée semblait terminée, bien que nous ayons écarté le fichier comme conseillé par Discourse. Ils ont ensuite rencontré un tas de problèmes avec les sauvegardes qui expiraient et renvoyaient des erreurs, avant de finalement nous dire qu’il y avait un fichier complet. Mais lorsque j’ai essayé de restaurer le fichier, après plusieurs heures pour extraire l’archive, il s’est plaint que le dump était manquant. L’inspection du fichier à l’aide de tar -tf a confirmé qu’il n’y avait pas de dump dedans (en regardant d’autres sauvegardes complètes, c’est normalement le premier fichier de l’archive). Comme c’était un dimanche, je n’ai pas pu contacter Discourse, et nous avions promis de terminer la migration avant lundi matin, j’ai donc effectué une sauvegarde de la base de données uniquement (environ 7 Go) et je l’ai utilisée pour migrer.
Discourse essaie d’aider, mais il n’y a vraiment que tellement qu’ils peuvent faire maintenant, car nous avons terminé la migration et sommes sur notre environnement auto-hébergé depuis dimanche après-midi. La solution la plus simple serait qu’ils gardent notre bucket S3 et notre CDN actifs (moyennant des frais), mais ils ont dit que ce n’était pas possible. Je pense que nous allons devoir perdre les images historiques, honnêtement.
Ceci est réparable. Téléchargez simplement le contenu du bucket S3 dans votre répertoire de téléchargements local, puis effectuez un remap sur votre base de données, en réécrivant les URL du CDN et du bucket vers l’URL de votre instance.
1 « J'aime »
Quelques problèmes : la taille des images téléchargées saturerait le SSD de notre nouveau VPS, et nous n’avons pas la possibilité d’attacher un disque supplémentaire. Peut-être pourrions-nous simplement en prendre un sous-ensemble, bien que je ne sois pas sûr de la façon dont cela fonctionnerait en regardant la structure du répertoire. De plus, nous avons déjà configuré le site pour utiliser S3 pour les téléchargements au lieu du stockage local.
Ok, alors copiez leur S3 (ou sauvegarde depuis S3) vers votre S3 et remappez ?
1 « J'aime »
Oui, j’espère que c’est possible !
1 « J'aime »
Ah. Je vois. Oui, une fois que vous êtes en ligne, vous êtes engagé. Il est tout à fait possible de déplacer les fichiers vers S3 avant qu’ils ne soient supprimés.
Vous avez toujours eu besoin de suffisamment d’espace pour conserver toutes les images afin d’effectuer la restauration. Vous pourriez copier les images une par une. Il existe également des outils qui copient les fichiers directement, je crois.
Le plan initial était d’utiliser une VM Azure temporaire pour restaurer, avec un grand disque attaché, puis de renvoyer vers S3, de prendre une autre sauvegarde une fois terminée et enfin de déplacer vers notre VPS (en essayant de réduire les coûts).
J’ai donc un tar.gz contenant toutes les téléversements et je peux les intégrer directement dans notre bucket S3 en conservant la structure des répertoires (je pense que l’outil de téléversement AWS standard peut le faire de nos jours, sinon il y a la CLI). Il pourrait y avoir une considération de propriété / permissions bien que peut-être pas.
Après cela, il y aurait le remappage - je ne suis pas sûr de la différence entre discourse.remap et dbhelper.remap. Je chercherais à tester tout cela sur une installation factice avec quelques fichiers d’abord.
1 « J'aime »