Bonjour
Depuis 18h les services ne sont plus disponibles.
Un des disques a à nouveau posé problème. Lors du reboot le disque a
été corrompu et a décidé de ne plus vouloir rebooter.
Une opération est en cours pour restaurer l'état du disque, j'espère
que cela se passera bien.
Pour le moment aucune idée avant rétablissement du service.
Km
merci pour l'info, doigts croisés
Bonsoir
Le changement de disque ne s'est pas passé comme prévu. L'opération
sera plus longue que prévue.
Je pense que ce sera encore en panne pour une bonne partie du samedi.
Un des disques dur est abîmé et la bascule sur le disque sain n'a pas
plus au serveur. Il est probable qu'une restauration depuis une
sauvegarde sera à faire.
Toutefois vu l'heure et la fatigue, je continuerai les opérations demain matin.
Bonne soirée
Km
Bonjour à tous
Petit point de situation intermédiaire. Pour le moment le service est
encore en maintenance bien que le site puisse potentiellement
répondre.
Hier soir le disque dur qui me pose problème depuis un petit moment
(ce qui a obligé plusieurs redémarrage serveur) a décidé d'être un peu
plus récalcitrant.
Comme j'avais enfin un disque de remplacement, j'ai voulu en profiter
pour faire l'opération en bonne et due forme et enfin remplacer ce
disque dur.
Pour comprendre le serveur fonctionne avec 2 disques dur en miroir
(raid1) ce qui signifie que si un disque rend l'ame l'autre est
toujours là pour assurer la continuité de service. L'opération
consistait donc :
-* à retirer le disque problématique,
-* redémarrer en mode dégradé donc sur un seul disque ,
-* vérifier que les services sont toujours opérationnels
-* éteindre
-* ajouter un nouveau disque
-* resynchroniser les disques entre eux
Sauf que ...
-* j'ai rencontré des problèmes pour identifier physiquement le disque
dur, à chaque reboot j'obtenais le même nom, ce qui est problématique
pour être sur de retirer le mauvais disque
-* lors du reboot avec le nouveau disque, le système n'a pas trop
apprécié et des données ont été corrompues
-* malgré une restauration du disque sain, la base de donnée est
restait corrompue
Du coup
-* depuis le disque problématique (qui fonctionne en lecture) j'ai
transféré la majorité des données de l'instant T
-* j'ai lancé un scan du disque sain mais corrompu
-* j'ai relancé le système avec le disque sain nettoyé
-* j'ai effectué une réinstallation de la base de donnée avec les
donnée les plus récentes possible, qui devrai être entre 17 et 18 du
vendredi 27 mars
Pour le moment :
-* le serveur est à nouveau en ligne en lecture seule
-* les données semblent plutôt récente
-* les dépot git sont en inspection d'intégrité
C'est donc toujours en cours
Km
Bonjour
Bonne nouvelle cela avance et on est plus proche de la fin que du
début (sauf surprises de dernières minutes, oui au pluriel en général
si cela arrive c'est en escadron).
La base de donnée du gitea a été rétablie. On ne constate pas de perte
de données à ce niveau.
Concernant les dépôts git, certains dépôts ont été abîmés mais la
majeure partie a pu être rétablie dans un état stable. Un seul dépôt
est noté comme cassé.
On avait 2 commits de retard par rapport au svn ils ont bien été synchronisés.
J'ai donc réouvert les accès en écriture sur les dépôts contrib.
Pour information voici la liste des différents dépôts impactés
Encore en erreur :
* spip/ecrire.git
cela n'est pas bloquant car c'est un projet en lecture seule pour
le moment (prochaine étape avec composer).
On travaille pour le moment spip/spip.git
Ayant eu un problème et rétabli dans un état considéré stable :
* spip-contrib-outils/archives_from_gitea.git
* spip-contrib-outils/git_loader.git
* spip/prive.git
* spip-contrib-squelettes/spipr-dist.git
* spip-contrib-squelettes/escal.git
* nicod_/spip.git
* spip-contrib-extensions/deconnexion_auto.git
* spip-contrib-extensions/mailsubscribers.git
* spip-contrib-extensions/moncompte.git
* spip-contrib-extensions/abonnements.git
* spip-contrib-extensions/rainette.git
* spip-contrib-extensions/autorisations_etendues.git
* spip-contrib-extensions/prix.git
* spip-contrib-extensions/metasplus.git
* spip-contrib-squelettes/html5up_alpha.git
Comme le dépôt cassé est sur l'organisation SPIP j'ai encore un
travail à faire pour être complètement serein.
Pour le moment la synchronisation git > svn n'a pas été rétablie sur
cette organisation.
Km
Bonjour,
Une question d'ordre général sur cette infra: y-a-t-il des sauvegardes
en dehors du miroir (qui n'en n'est pas une) ? et y-a-t-il quelque part
une description de cette infra ?
PS: absolument aucune pensée polémique, juste la volonté de comprendre
et de voir si éventuellement on peut aider.
Bonjour
La question est justifiée. Et la réponse est oui mais ...
Comme sans surprise ce n'est quand on rencontre le problème qu'on constate qu'il manque un bout qui semblait pourtant une évidence.
La base de donnée est sauvegardée quotidiennement, les outils de déploiement sont versionnés mais en effet la documentation avait oublié 2/3 points de "détail" qu'il a fallu me souvenir. Et je vais renforcer le système de sauvegarde externe pour être un peu plus complet pour avoir plus un instantané qu'une solution pour reconstruire la forge. Comme c'est 95% de dépôts git reconstruire n'est en soit pas un problème mais cela est plus long et pour certains aspect moins pratique.
Km
Bonjour
En l'état je considère que le service est entièrement rétabli.
N'hésitez pas à me faire un retour si vous voyez un truc étrange.
Bonne journée à tous et toutes.
Km
Merci à toi Azerttyu 
!
Franck
-----Message d'origine-----