chore: retire data/ du suivi git
This commit is contained in:
Cedric Abonnel
@@ -1,134 +0,0 @@
|
||||
*(Méthode basée sur l’installation via le script communautaire Proxmox : [https://community-scripts.github.io/ProxmoxVE/scripts?id=uptimekuma](https://community-scripts.github.io/ProxmoxVE/scripts?id=uptimekuma))*
|
||||
|
||||
Lorsque Uptime Kuma rencontre des problèmes de démarrage, des erreurs dans la base SQLite, ou des comportements anormaux après une mise à jour, il peut être nécessaire d’effectuer une série de vérifications et de corrections. Le guide ci-dessous détaille les étapes recommandées pour diagnostiquer et réparer votre instance Uptime Kuma tout en minimisant les risques de perte de données.
|
||||
|
||||
---
|
||||
|
||||
## 1. Arrêt du service Uptime Kuma
|
||||
|
||||
Avant toute manipulation sur les fichiers de données, il est indispensable d’arrêter correctement le service :
|
||||
|
||||
```bash
|
||||
systemctl stop uptime-kuma
|
||||
```
|
||||
|
||||
L’arrêt garantit que la base SQLite ne subit aucune écriture pendant la maintenance. Sans cela, on risque d’aggraver les corruptions ou de provoquer des pertes de données.
|
||||
|
||||
---
|
||||
|
||||
## 2. Accéder au dossier de l’application
|
||||
|
||||
Le script communautaire installe généralement Uptime Kuma dans `/opt/uptime-kuma` :
|
||||
|
||||
```bash
|
||||
cd /opt/uptime-kuma
|
||||
```
|
||||
|
||||
Ce répertoire contient le code de Kuma ainsi que le dossier `data`, qui renferme toutes les données utilisateur, les paramètres, les historiques de monitoring et la base de données `kuma.db`.
|
||||
|
||||
---
|
||||
|
||||
## 3. Sauvegarde des données avant intervention
|
||||
|
||||
Avant toute réparation, il est impératif de créer une copie de la base SQLite :
|
||||
|
||||
```bash
|
||||
cp -r data data-backup-$(date +%Y%m%d)
|
||||
```
|
||||
|
||||
Cette sauvegarde permet de revenir en arrière en cas de problème.
|
||||
Elle inclut notamment :
|
||||
|
||||
* la base de données `kuma.db`
|
||||
* les historiques de monitoring
|
||||
* les configurations des sondes
|
||||
* les paramètres de l’interface
|
||||
|
||||
⚠️ **Ne jamais sauter cette étape**, surtout si vous modifiez la base à la main.
|
||||
|
||||
---
|
||||
|
||||
## 4. Vérification de l’intégrité de la base SQLite
|
||||
|
||||
On se rend ensuite dans le dossier des données :
|
||||
|
||||
```bash
|
||||
cd data/
|
||||
```
|
||||
|
||||
Puis on effectue une vérification complète :
|
||||
|
||||
```bash
|
||||
sqlite3 kuma.db "PRAGMA integrity_check;"
|
||||
```
|
||||
|
||||
Cette commande retourne :
|
||||
|
||||
* **ok** → la base est saine
|
||||
* un ou plusieurs messages d’erreur → corruption ou index endommagé
|
||||
|
||||
Selon le résultat, il faudra peut-être appliquer une des corrections suivantes.
|
||||
|
||||
---
|
||||
|
||||
## 5. Suppression d’un paramètre problématique dans la base
|
||||
|
||||
Certaines versions d’Uptime Kuma ont rencontré un problème lié à l’entrée `migrateAggregateTableState` dans la table `setting`.
|
||||
Si cette clé est corrompue ou mal migrée, elle peut empêcher le service de démarrer.
|
||||
|
||||
La correction consiste à supprimer cette entrée :
|
||||
|
||||
```bash
|
||||
sqlite3 kuma.db "DELETE FROM setting WHERE key = 'migrateAggregateTableState';"
|
||||
```
|
||||
|
||||
Cette action force Uptime Kuma à recréer proprement l’état de migration au prochain démarrage.
|
||||
|
||||
---
|
||||
|
||||
## 6. Solution extrême : vider toute la table `heartbeat`
|
||||
|
||||
Si les problèmes concernent uniquement les historiques (table heartbeat corrompue), une solution radicale consiste à vider la table :
|
||||
|
||||
```bash
|
||||
sqlite3 kuma.db "DELETE FROM heartbeat;"
|
||||
```
|
||||
|
||||
⚠️ Cette commande supprime **tout l’historique des sondes**, mais ne touche pas aux sondes ni aux paramètres.
|
||||
À utiliser uniquement en dernier recours si :
|
||||
|
||||
* la vérification SQLite échoue
|
||||
* Uptime Kuma ne démarre plus
|
||||
* l’historique est corrompu
|
||||
|
||||
---
|
||||
|
||||
## 7. Redémarrage du service
|
||||
|
||||
Une fois les corrections effectuées :
|
||||
|
||||
```bash
|
||||
systemctl start uptime-kuma
|
||||
```
|
||||
|
||||
Si la base est correcte, Uptime Kuma devrait redémarrer normalement.
|
||||
|
||||
---
|
||||
|
||||
## 8. Consultation des journaux pour valider les corrections
|
||||
|
||||
Pour suivre en temps réel les messages du service et détecter d’éventuelles anomalies persistantes :
|
||||
|
||||
```bash
|
||||
journalctl -u uptime-kuma -f
|
||||
```
|
||||
|
||||
Points à surveiller dans les logs :
|
||||
|
||||
* erreurs SQLite
|
||||
* migrations bloquées
|
||||
* permissions incorrectes
|
||||
* modules Node.js manquants
|
||||
* services stoppés subitement
|
||||
|
||||
Les journaux permettent de confirmer que la base est stable et que le service démarre correctement.
|
||||
@@ -1,13 +0,0 @@
|
||||
{
|
||||
"uuid": "5a0cced3-40d0-46bf-8501-b533f3c2608e",
|
||||
"slug": "correction-et-reparation-d-une-installation-uptime-kuma",
|
||||
"title": "Correction et réparation d’une installation Uptime Kuma",
|
||||
"author": "cedric@abonnel.fr",
|
||||
"published": true,
|
||||
"published_at": "2025-11-26 08:33:49",
|
||||
"created_at": "2025-11-26 08:33:49",
|
||||
"updated_at": "2025-11-26 08:33:49",
|
||||
"revisions": [],
|
||||
"cover": "cover.jpg",
|
||||
"category": "informatique"
|
||||
}
|
||||
Reference in New Issue
Block a user