La base de données `life.db`

Tout ton serveur tient dans un fichier. Ce chapitre explique ce qu'il contient, comment le sauvegarder, comment le lire quand tu as besoin d'une réponse que le jeu ne donne pas — et ce qu'il ne contient pas, ce qui surprend beaucoup de monde.

1. Un fichier, 18 tables #

life.db est une base SQLite posée dans Servers/<TonProfil>/. Pas de serveur de base à démarrer, pas de mot de passe, pas de port. Le jeu ouvre le fichier, écrit dedans, le referme.

Voici ce qu'il y a dedans, relevé sur un serveur TeamKit réel :

Sur un serveur qui tourne depuis plusieurs mois avec 431 comptes et 378 personnages, le fichier pèse environ 9 Mo. C'est minuscule : tu peux en garder des dizaines de copies sans réfléchir à la place.

✅ À retenir

• Un seul fichier, 18 tables, une dizaine de mégaoctets.
• Accounts porte aussi les bannissements et le niveau admin.

2. Ce que la base ne garde PAS — et c'est important #

Trois choses vivent uniquement dans la mémoire du serveur et disparaissent à chaque redémarrage :

Les tickets d'assistance. Il n'existe aucune table Tickets. Quand un joueur ouvre une demande au staff, elle vit en mémoire. Un redémarrage efface la file d'attente : les joueurs qui attendaient une réponse n'en auront jamais, et ne sauront pas pourquoi. C'est vérifiable — le jeu enregistre pourtant les avertissements, donc ce n'est pas un oubli de lecture.

L'historique des sanctions. La table Accounts sait qu'un compte est banni maintenant, mais pas qui l'a banni, quand, ni pourquoi. Le bannissement est un état, pas un journal.

Ce qui s'est passé depuis la dernière sauvegarde automatique. Voir section 4.

Ces trois trous sont exactement ce que les plugins TeamKit comblent (chapitre 05). Mais tant que tu n'en as pas installé, sache que ces informations n'existent nulle part.

✅ À retenir

• Un redémarrage efface tous les tickets en attente. Préviens tes joueurs avant de redémarrer.
• La base sait qui est banni, pas qui l'a banni ni pourquoi.

3. Sauvegarder : la seule chose vraiment importante #

Trois niveaux, du plus simple au plus solide.

Niveau 1 — la copie manuelle. Par SFTP, télécharge life.db. C'est tout. Range-le avec la date dans le nom : life-2026-09-07.db. Fais-le avant chaque manipulation risquée.

Niveau 2 — le dossier Backups/. Ton profil contient un dossier Backups/ où le serveur dépose des copies horodatées. Va y jeter un œil : tu y trouveras des fichiers du type life-25-8-2026-13-38.db. Ce sont des copies automatiques, mais ne compte pas dessus seul — elles vivent sur le même disque que l'original.

Niveau 3 — les sauvegardes AMP. Page Backups du panel. Elles prennent l'instance entière : base, configuration, plugins. C'est le seul niveau qui te sauve si tout le dossier disparaît.

Le piège : une sauvegarde AMP arrête ton serveur le temps de préparer les fichiers, sauf si tu coches « Backup While Running ». Une sauvegarde horaire non cochée coupe donc ton serveur toutes les heures.

La règle d'or : une copie qui vit sur le même disque que l'original n'est pas une sauvegarde. Télécharge-en une chez toi, de temps en temps.

✅ À retenir

• Télécharge life.db chez toi avant toute manipulation. C'est trente secondes.
• Une sauvegarde AMP arrête le serveur si « Backup While Running » n'est pas coché.

4. Le décalage entre le jeu et le fichier #

Le serveur n'écrit pas la base en continu. Il l'écrit toutes les 18 - Sauvegarde auto secondes, 1800 par défaut.

Entre deux écritures, ce qui se passe en jeu n'existe que dans la mémoire du serveur. Si le processus s'arrête brutalement — plantage, coupure, manque de mémoire — cette tranche est perdue.

Le joueur qui vient d'acheter une voiture à 45 000 se reconnecte sans la voiture et sans l'argent. De son point de vue, le serveur l'a volé.

Deux gestes qui limitent les dégâts :

• Baisse 18 - Sauvegarde auto à 900 secondes sur un serveur actif.
• Garde 19 - Déconnecter les joueurs avant arrêt activé : sur un arrêt propre, le serveur écrit avant de s'éteindre, et rien n'est perdu.

Un redémarrage volontaire depuis le panel est un arrêt propre. Un plantage ne l'est pas.

✅ À retenir

• Un redémarrage propre ne perd rien. Un plantage perd jusqu'à l'intervalle entier.
• 19 - Déconnecter les joueurs avant arrêt est ce qui rend l'arrêt propre.

5. Lire la base sans rien casser #

Il arrive qu'on ait besoin d'une réponse que le jeu ne donne pas : combien de comptes au total, qui possède ce véhicule, quels comptes sont bannis.

La règle absolue : ne travaille jamais sur le fichier du serveur. Télécharge une copie et ouvre la copie. Écrire dans la base pendant que le serveur tourne peut la corrompre — et une base SQLite corrompue, c'est ton serveur entier.

Pour lire une copie, l'outil le plus simple est DB Browser for SQLite (gratuit, Windows/Mac/Linux). Tu ouvres le fichier, tu vois les tables, tu cliques.

Quelques questions courantes et leur réponse :

-- combien de comptes au total
SELECT COUNT(*) FROM Accounts;

-- les comptes actuellement bannis
SELECT * FROM Accounts WHERE Banned = 1;

-- les personnages les plus riches
SELECT Firstname, Lastname, Bank FROM Characters ORDER BY Bank DESC LIMIT 20;

Les noms exacts des colonnes peuvent varier selon la version du jeu : ouvre la table dans DB Browser et regarde avant d'écrire une requête.

✅ À retenir

• Jamais sur le fichier du serveur. Toujours sur une copie téléchargée.
• DB Browser for SQLite suffit à tout ce dont tu auras besoin.

6. Restaurer une sauvegarde #

Le jour où ça tourne mal :

1. Arrête le serveur depuis la page Status. C'est obligatoire — remplacer le fichier pendant qu'il tourne le corrompt.
2. Par SFTP, renomme l'actuel life.db en life.db.casse. Ne le supprime pas : il contient peut-être encore quelque chose de récupérable.
3. Envoie ta sauvegarde et nomme-la exactement life.db.
4. Redémarre.
5. Connecte-toi en jeu et vérifie avant d'annoncer quoi que ce soit à tes joueurs.

Tu perdras tout ce qui s'est passé entre la sauvegarde et maintenant. Dis-le clairement à ta communauté, avec la date et l'heure de la sauvegarde restaurée. Un serveur qui explique une perte est pardonné ; un serveur qui la cache ne l'est pas.

✅ À retenir

• Arrêter le serveur AVANT de toucher au fichier. Sans exception.
• Renommer l'ancien plutôt que le supprimer.

7. life.db.old : qu'est-ce que c'est #

Tu verras souvent un life.db.old à côté de la base. C'est une copie que le jeu garde de la version précédente.

Ce n'est pas une sauvegarde sur laquelle compter : elle est écrasée régulièrement et vit sur le même disque. Considère-la comme un filet de secours de dernière minute, pas comme une stratégie.

✅ À retenir

• life.db.old est un filet, pas une sauvegarde. Ne construis rien dessus.

Checklist du chapitre #

• J'ai une copie de life.db téléchargée chez moi
• Je sais où est le dossier Backups/ de mon profil
• 18 - Sauvegarde auto est réglé selon ma fréquentation
• 19 - Déconnecter les joueurs avant arrêt est activé
• J'ai installé DB Browser for SQLite pour lire mes copies
• Je sais que redémarrer efface les tickets en attente
• Si « Backup While Running » n'est pas coché, je sais que la sauvegarde arrête le serveur

❓ Si ça ne marche pas #

Mes joueurs disent avoir perdu leur progression. Regarde 18 - Sauvegarde auto et cherche un plantage dans la console au moment indiqué.

La base est corrompue, le serveur ne démarre plus. Arrête, renomme life.db en life.db.casse, mets une sauvegarde à la place. Si tu n'en as aucune, regarde Backups/ et life.db.old.

J'ai ouvert la base pendant que le serveur tournait et maintenant il bugue. Arrête, restaure une sauvegarde. Et ne recommence pas : travaille sur des copies.

Je ne trouve pas la table des tickets. Elle n'existe pas. Voir section 2.

Mon serveur s'arrête toutes les heures. Tu as une sauvegarde horaire planifiée sans « Backup While Running ». Chapitre 07.