La sauvegarde des données a soudainement diminué, la restauration des données réduites a été anormale, le site Web ne pouvait pas interagir normalement. Heureusement, le compartiment de stockage Amazon S3 a pu trouver des données historiques, sinon la perte aurait été incommensurable.
1 « J'aime »
Y a-t-il eu des changements de configuration pendant cette période qui auraient pu affecter l’inclusion des téléchargements dans vos sauvegardes ?
2 « J'aime »
Mis à niveau, j’ai utilisé un thème, j’ai ajouté un plugin personnalisé au thème (css personnalisé), l’utilisateur peut désactiver la palette de couleurs, j’ai utilisé data.yml, web_only.yml, après avoir restauré les données avec 262 Mo, la sauvegarde n’est plus que de 154 Mo, ces données de sauvegarde sont probablement encore problématiques
1 « J'aime »
Avez-vous opté pour une configuration à deux conteneurs à ce moment-là, ou l’utilisiez-vous depuis le début ?
1 « J'aime »
Je l’ai toujours utilisé comme ça, quelles pourraient en être les causes probables ?
1 « J'aime »
J’ai essayé de restaurer ma dernière sauvegarde il y a quelques jours et le téléchargement sur mon tableau de bord a été refusé. J’ai cru un instant que ma sauvegarde était perdue, alors j’ai essayé une autre sauvegarde en téléchargeant sur FTP et devinez quoi ? Restaurée ! Mais cela s’est produit de la même manière et je voudrais connaître la raison.
Je crains d’être plus familier avec l’installation standard et je ne suis pas sûr si la configuration à deux conteneurs a des particularités qui pourraient être pertinentes ici.
Laissez-moi passer ceci à Installation et voir si nous pouvons obtenir des avis plus expérimentés. 
(@pfaffman 
)
1 « J'aime »
J’utilisais auparavant l’installation standard, mais l’installation standard a un problème : chaque fois que je modifie app.yml, mon site Web ne peut pas être accédé normalement. Si j’utilise data.yml ou web_only.yml, je peux modifier web_only.yml sans affecter l’accès au site Web. L’installation standard a-t-elle une fonction similaire, et comment l’utiliser spécifiquement ?
Non. La seule différence est qu’une reconstruction ne reconstruit que les parties rails et nginx. La base de données et redis restent les mêmes. Celles-ci changent rarement, donc elles n’ont pas besoin d’être reconstruites. Cela fonctionne exactement de la même manière. Vous comprenez cela très bien. (La seule complication survient lors d’une mise à jour de postgres ou de redis, ce qui arrive environ une fois par an, bien qu’il y ait eu quelques mises à jour de base de données dues aux exigences du plugin IA. Donc, si vous n’utilisiez pas le plugin IA, vous seriez tout à fait bien, mais si vous l’utilisiez, vous obtiendriez des erreurs de base de données confuses si vous ne reconstruisiez pas également le conteneur de données.)
Ma supposition est qu’ils ont déplacé les actifs vers s3 et que les téléchargements locaux ne sont donc pas inclus. Ceci est cohérent avec leur affirmation selon laquelle ils ont pu restaurer des éléments depuis s3. Ou peut-être ont-ils supprimé certains messages qui contenaient des téléchargements, de sorte que ces téléchargements n’ont pas été inclus dans les sauvegardes ultérieures.
De plus, il semblait un peu qu’ils aient effectué une restauration sans attendre qu’elle se termine complètement.
1 « J'aime »
J’ai bien utilisé un plugin IA. À quoi dois-je faire attention pour que les données de sauvegarde puissent être utilisées ? Comment devrions-nous gérer ce genre de problème
Cela signifie que tant que data.yml n’est pas reconstruit, il n’y a pas de problème, ou est-il nécessaire d’utiliser app.yml, ou ce type de problème existe-t-il à la fois dans le plan web_only de data.yml et dans le plan app.yml ?
Le problème est que lors de ma sauvegarde, le conteneur construit par data.yml n’était pas pris en charge, et la base de données a été mise à niveau. Si la reconstruction de data.yml est mise à niveau, il n’y aura aucun problème même si vous effectuez une mise à niveau majeure de la base de données, et il n’y aura alors aucun problème avec la sauvegarde et sa restauration. Comment puis-je savoir que votre base de données a été considérablement modifiée ?
Le problème est que lorsque j’ai sauvegardé, le conteneur construit par data.yml n’était pas pris en charge, et la base de données a été mise à niveau. Si la reconstruction de data.yml est mise à niveau, il n’y aura aucun problème même si vous effectuez une mise à niveau majeure de la base de données, et il n’y aura alors aucun problème avec la sauvegarde et sa restauration. Comment puis-je savoir que votre base de données a été considérablement modifiée ?
@sober, à titre de note de processus, il est beaucoup plus facile pour ceux qui lisent / souhaitent aider si vous incluez une traduction en anglais dans vos publications. Pourriez-vous en ajouter une. 
5 « J'aime »
Je comprends maintenant que le problème était une mise à niveau majeure de la base de données qui a causé des problèmes de sauvegarde.
3 « J'aime »
Lorsque Discourse est mis à niveau, comment puis-je m’assurer que la version mise à niveau est en version bêta au lieu de la version de développement ? Après le dernier échec de sauvegarde, je dois m’inquiéter des opérations de mise à niveau et de restauration de sauvegarde.
1 « J'aime »
Quoi ? Eh bien, j’attendrai une confirmation car je ne sais pas si cela va casser quelque chose ici.
Je ne veux mettre à niveau que beta2, pas beta2-dev, car j’ai peur que dev ne soit pas stable, et la sauvegarde de données récente ne peut pas être restaurée normalement, ce qui a presque causé une perte de données. J’ai utilisé la sauvegarde précoce pour la sauvegarde, mais les données ont toujours été perdues pendant une période de temps.
1 « J'aime »
Ils ne le sont pas, c’est juste un changement récent du système de versionnement. Techniquement, vous ne êtes même pas censé voir les étiquettes -dev.
3 « J'aime »