Avant de commencer
Conservez les accès de livraison de votre espace client et vérifiez la console avant toute modification sensible. Repérez les fichiers de chaque jeu, ses bases, ses dépendances et une destination de sauvegarde distincte. Les outils présentés dans ce guide ne sont pas annoncés comme préinstallés.
Protégez les accès avant de partager
Le SSH est fourni sur le port de livraison indiqué, par défaut 22 sur les offres concernées. Utilisez des secrets uniques et protégez les clés privées. Ne partagez pas le compte root avec tous les membres de la communauté. La documentation OpenSSH d’Ubuntu décrit les clés et la configuration ; appliquez une méthode adaptée à votre distribution plutôt qu’un fichier de configuration copié sans vérification.
Distinguez administrateur et processus de jeu
Root permet d’administrer la VM. Le processus du jeu peut utiliser un compte de service aux droits limités, avec ses répertoires et secrets séparés. Accordez uniquement les accès nécessaires aux collaborateurs. Protégez les identifiants RCON, SQL et de panel comme le mot de passe système. Des ports différents ne constituent pas une authentification et une interface publique doit conserver un contrôle d’accès.
Planifiez les mises à jour
Suivez la distribution Linux, le runtime et le serveur de jeu séparément. Un nouvel artifact FXServer ou une mise à jour de mod peut demander une adaptation. Sauvegardez avant changement, lisez les exigences et testez sur une copie si possible. Ne supposez pas que tous les mods suivront immédiatement une nouvelle version du jeu. Prévenez la communauté lorsqu’un arrêt ou une maintenance est nécessaire.
Définissez le contenu à sauvegarder
Une archive utile inclut mondes, configurations, données persistantes, extensions personnalisées et bases associées. Un export SQL doit être cohérent avec l’état des fichiers. Utilisez les fonctions documentées du jeu ou une fenêtre d’arrêt des écritures lorsque nécessaire. Une simple copie pendant une modification de base n’est pas automatiquement exploitable. Consignez également les versions et dépendances indispensables au redémarrage.
Conservez une copie indépendante et testez-la
Une sauvegarde uniquement dans le disque de la VM partage les risques de celle-ci. Prévoyez une destination distincte, des permissions limitées et une rétention adaptée à votre fréquence de changements. Testez la restauration dans un environnement isolé : décompresser une archive ne suffit pas. Vérifiez que le monde charge, que la base correspond et que les accès d’administration fonctionnent sans exposer une deuxième copie publique par erreur.
Situez la protection réseau à sa juste place
Peeryx agit en amont sur les attaques réseau dans le périmètre réel de l’offre. La capacité globale annoncée n’est pas un débit réservé par VPS ou une garantie contre chaque attaque. Elle ne corrige pas un plugin vulnérable ou un mot de passe divulgué. Associez protection réseau, contrôle d’accès, mises à jour, supervision et sauvegardes ; choisissez l’hébergement avec panel si vous ne souhaitez pas administrer Linux.
Selon votre situation
| Situation | Prochaine vérification |
|---|---|
| Un collaborateur doit accéder au serveur | Attribuez un accès limité adapté à sa tâche, plutôt que de partager root et tous les secrets. |
| Vous préparez une mise à jour du monde | Sauvegardez les données et la base au même état, puis vérifiez un retour arrière. |
| Votre sauvegarde reste dans la VM | Préparez une copie indépendante et un test de restauration avant d’en avoir besoin. |
Sources officielles
Ces documents décrivent les protocoles et logiciels concernés. Les conditions de votre service et sa configuration restent à vérifier.