J’ai un site qui envoie une sauvegarde de 20 Go vers Wasabi S3. Ça fonctionne. La plupart du temps.
Mais parfois, l’upload vers S3 échoue et le fichier .tar.gz local est conservé. Et finalement, le disque se remplit, me laissant avec un disque plein, le fichier .tar non compressé (car il n’y avait pas assez d’espace pour la version compressée), et bientôt, un site cassé parce que le disque est plein.
Avant d’abandonner Wasabi, j’aimerais essayer de voir s’il y a des indices.
J’ai examiné production.log, production.errors ainsi que les journaux de sidekiq et unicorn, mais je ne vois nulle part le terme “acku”, ni le jour où la sauvegarde a échoué, ni quand elle a réussi. Ne devrait-il pas y avoir un journal quelque part ?
Vous devriez recevoir un message privé avec la sortie du journal si cela échoue. Il est envoyé directement à vous s’il s’agit d’une sauvegarde manuelle dans l’interface utilisateur, ou au groupe des administrateurs s’il s’agit d’une sauvegarde automatique.
Une exception survenue pendant la sauvegarde devrait également apparaître dans /logs et, je pense, dans l’un des fichiers journaux. Essayez de rechercher EXCEPTION:.
Cependant, le fait que des fichiers temporaires soient conservés me fait me demander si Sidekiq, voire Docker ou l’hôte, ne redémarrent pas pendant la sauvegarde. Cela expliquerait pourquoi le nettoyage ne s’exécute pas et pourquoi vous ne recevez pas de message privé.
C’est très étrange. Je n’ai reçu aucun avis d’échec, même pour celui où il n’y avait qu’un fichier .tar et un disque presque plein (c’est un site à jour sur tests-passed).
C’est comme si backup location avait simplement été modifié ces jours-là, mais il n’y a rien dans les journaux. Je vois des notifications « réussies » dans les messages d’administration pour les sauvegardes lancées depuis l’interface web, mais aucune notification d’échec. J’ai déplacé backup_location vers un paramètre d’environnement (ENV).
Peut-être que je n’abandonnerai pas Wasabi tout de suite…