Voici plus en détail comment la migration s’est passée.
De manière générale, pas de souci.
Tout d’abord, j’ai été étonné que la migration commence sitôt le container démarré. En soi, ça ne pose pas de problème.
Par contre, la migration a immédiatement commencé à 23%.
Dans les tâches, on voit bien la progression.
C’est lent, mais ça avance.
Pendant ce temps, Gladys est ralentie mais pas inutilisable.
1Go de RAM utilisé.
Le résultat, dingue, une db de 65Mo au lieu de 11,4Go !
Par contre, l’étape suivante, la purge… Fût pénible !
Plusieurs très longues heures pendant lesquelles Gladys était, chez moi, proche de la paralysie…
Ce matin, je vois que
Et ça ne bouge plus.
Puis je reçois une notification de redémarrage de Gladys (peut-être watchtower ?). Et dans les tâches :
(Il y a une coquille : ‹ a échoué › sera plus juste)
Toutefois :
Je lance donc un nettoyage de la base de données qui, comme prévu, bloque Gladys une heure environ.
Mais après vérification, je constate que l’ancienne db n’est pas vide :
J’ai donc relancé les étapes de purge et de nettoyage de la db et hop (ah oui, et un redémarrage du container manuel pour vider le db-wal).
Et puisqu’on parlait de sauvegarde, un screen de la mienne :
Évidemment, c’est très peu, voire pas compressé (est-ce donc encore nécessaire?)
Temps total… Près de 30h…
On est d’accord que les étapes de purge et de nettoyage ne sont pas indispensables mais elles ont permis de régler mon problème de stockage
