Serveur en 1.5.2

Il y a d'autres plugins, mais ils sont encore plus vieux.

Y'en a surement d'autres, mais je préfèrerais un système stable et suivi. Depuis la création du serveur, je crois qu'on a pris 3 plugins différents pour les backups...
C'est même étonnant qu'il n'y ait rien dans craftbukkit ?

Pour la grande majorité, la cause du peut de suivis des plugins de backup est dû aux hébergeurs de serveurs de jeux, qui propose des fonctionnalité de backup auto sur des panels facile à administrer rendant inutile ledit plugin.

Après il y a des solutions plus pratique outrepassant le Bukkit, où un script de backup auto ou un simple logiciel dédié pourrais être mis en œuvre très facilement suivant l'OS du serveur.

RetroGeek2 a écrit:Après il y a des solutions plus pratique outrepassant le Bukkit, où un script de backup auto ou un simple logiciel dédié pourrais être mis en œuvre très facilement suivant l'OS du serveur.

Comme le disait Warzouz suite à ma suggestion, c'est certainement parce que Minecraft verrouille des fichiers en lecture empêchant un backup externe de récupérer l'ensemble des fichiers.

Ce qu'il pourrait être fait (j'essayerai si j'ai le temps) c'est de voir si on récupère bien tout avec une copie externe pendant qu'un serveur tourne et vérifie que la copie est cohérente.

Pour revenir sur le sujet du wither, il faudrait déjà trouver les masques qui sont, et j'en suis certains vu le nombre grandissant des nuits sans loots, extrêmement rares. Donc à mon avis, il ne risque pas d'y avoir d'invocation de wither avant un certain temps

Je confirme, aucun loot de wither squelettes ou même d'autre mobs... Ces trucs sont 200X plus rares que le diams pour une utilité qui... ben voila, à part les têtes de whiter squelettes, c'est juste de la déco...

En même temps, vous restez souvent dans le Nether pour buter des squelettes Wither ? ^^
Actuellement, ce sont les seules têtes lootables, les autres existent en tant qu'objet, mais on ne peut pas les obtenir à part avec du give.

Mortumee a écrit:Actuellement, ce sont les seules têtes lootables, les autres existent en tant qu'objet, mais on ne peut pas les obtenir à part avec du give.

Ah? Il me semblais que les zombies et autres lootaient ce genre de trucs :/

Je viens de tester sur un serveur local en marche, la commande "XCOPY" de Windows copie bien l'ensemble des fichiers à l'octet près (si tant est qu'on utilise les options /E et /H) et le serveur copié est fonctionnel.

Je ne vois donc pas, ici, la nécessité d'utiliser un plugin. On pourra donc, au besoin, se passer du plugin.

Oui, mais informaticien, tu connais bien la problématique des accès concurrentiel ?

Si pendant le save, un chunk est modifié puis sauvegardé. Ne peut-il pas y avoir des soucis ? Seul tu ne peux réellement tester ça.

Mince alors! Toutes ces nuits à buter le moindre monstre présent pour rien! Bon bah je crois que je me suis fait avoir

Oui moi aussi blooow...temps perdu

Warzouz a écrit:Oui, mais informaticien, tu connais bien la problématique des accès concurrentiel ?

Si pendant le save, un chunk est modifié puis sauvegardé. Ne peut-il pas y avoir des soucis ? Seul tu ne peux réellement tester ça.

Ah oui, c'est juste. Bon, tant pis

Ghomerr a écrit:

Warzouz a écrit:Oui, mais informaticien, tu connais bien la problématique des accès concurrentiel ?

Si pendant le save, un chunk est modifié puis sauvegardé. Ne peut-il pas y avoir des soucis ? Seul tu ne peux réellement tester ça.

Ah oui, c'est juste. Bon, tant pis

En fait lors du backup du dossier world de Minecraft comme tout autres fichiers du disque, il n'y a pas de problèmes de ce genre. La sauvegarde commence en temps réel avec des joueurs ou pas sur le serveur, à la milliseconde près et même si le fichier est en cours de modification comme le ferait un plugin. Il enregistrera la modification du fichier avant l'action suivante.

Sous Debian j'utilisais "Backup Manager" avec "CRON". il est possible de l'automatisé à heures "H" de votre convenance avec des fichiers de configuration très simple à mettre en œuvre pour les initier du monde UNIX/linux .

Backup Manager s'exécute en tant que super-utilisateur "ROOT", il a donc tous les droits requis sur tout les fichiers de la machine, c'est pour cela que sur certains fichiers si l'on est un utilisateur courant, l'accès peut nous être refusé.

Préférez, si je puis me permettre, une sauvegarde incrémentielle plus performante, plus rapide et sécurisé.

Je me permet de ne pas être d'accord. Je peux me tromper car je ne connais bien Unix.

Tu as un process qui gère 2 fichiers. Les 2 fichiers sont sauvegardés en même temps. Tu fais un très gros backup qui fait que les fichiers peuvent être sauvegardés à 1 minute d'interval. Pendant ce temps, le process enregistre les fichiers. Résultat : les fichiers sauvegardés ne sont pas cohérents, aboutissant à une un fichier de backup non fiable.

A ma connaissance, Unix ne gère pas de versioning intrinsèque...

Je reste persuadé que le principe de plugins est de couper la sauvegarde physique des fichiers de MC pendant le backup et de le réactiver ensuite. Ces commandes font bien partie du jeu de commande de base du serveur vanilla, d'ailleurs.

Ma curiosité me perdra. J'ai posé la question sur le forum de Bukkit pourquoi ils avaient rajouté le numéro de version dans les trucs Bukkit :P

http://forums.bukkit.org/threads/why-does-the-craftbukkit-packages-contain-the-version-number-now.118893/

On verra bien ce qu'il en ressort.

Côté Backup, je suis mitigé. Je pense que les OS sont censés déjà bien gérer l'accès concurrentiel aux fichiers. Dans le monde Java, c'est un gros dilemme, qui pose parfois de gros soucis, surtout lors des montés en charge (vu au boulot récemment >_<).

Concernant un serveur Minecraft, j'ai du mal à me positionner. Le plus sûr serait effectivement d'arrêter la sauvegarde pendant le backup pour s'assurer d'avoir la vision de la map à un instant t précis. Après, si Minecraft est bien fait, le fait de ne pas avoir la vision de toute la map au même instant, mais à des instants différés, ne devrait pas casser ladite map.

Le pire qui pourrait arriver c'est que le serveur écrive les données d'un chunk par exemple et qu'on en prenne qu'une moitié pendant le backup et on aurait alors un truc incohérent, comme tu le disais. De manière non transactionnelle, ça pourrait bien corrompre complètement les données.

Bref, ce qu'on peut faire en attendant que le plugin Backup soit mis à jour c'est d'essayer sur un serveur alternatif la solution de Retro et vérifier sa viabilité. Je vais envoyer un PM au mec qui développe le plugin pour savoir s'il compte mettre à jour bientôt.

Oui les OS gèrent les accès concurrentiel à UN fichier, mais pas à un système entier de fichiers. Or MC a de nombreux fichiers indépendants.

OK, j'ai ma réponse: http://forums.bukkit.org/threads/safeguarding-against-unchecked-and-potentially-damaging-plugins.116749/

C'est bien ce que je pensais, ou du moins, en partie. C'est pour obligé les développeurs à n'utiliser que le code de l'API Bukkit et non le code interne de CraftBukkit ou même du code natif de Minecraft.

Juste pour rebondir sur les accès concurrentiel et sur ce que je peut vous dire à ce sujet...(pour pousser un peut le truc)

Sur UNIX, l'OS traite séparément la lecture et l'écriture d'un fichier, l’entrelacement des données est possible lorsque plusieurs processus par threads écrivent dans le même fichier et pas seulement les lectures/écritures simultanées. Chaque processus doit respecter les autres en l’occurrence.

L'ordonnancement des threads permet à plusieurs threads "de même priorité" de s'exécuter tour à tour dans une partie du disque différente avant écriture sur l'emplacement du fichier!

Ce système de fichiers est bâtis sur le concept de l'inode. C’est un concept fondamental dans l'UFS. Un inode est une structure de données indexés dans un système de fichiers UNIX/linux. C'est le BTree !

Les systèmes de fichiers de type UNIX possède une particularité que NTFS ne peut fournir de part son architecture: La journalisation des fichiers, elle évite la corruption et la perte des données l'or d'un crash.

Ceci est que si une coupure de courant survient à l'instant ou le fichier est édité, les données seront sauvées. Avec Windows, les données sont manipulées dans la RAM. Sachant que la RAM est volatile, vous perdrez vos données si un incident électrique survient.

Les plus éclairés comprendrons que grâce à la journalisation, vous pourrez déplacer des fichiers en cours d'utilisation par un programme avant même d'être finalisés sans plantages ni corruptions des données écrite sur le disque. NTFS est incapable de supprimer, renommer, déplacer un fichier ouvert!



Édit: Correction de certaines fautes d’orthographe que je n'est pas pu voir sans correcteur avec mon Smartphone, remise en place de certains paragraphes, mise en forme plus assimilable. Je crois que je ne vais pas recommencer a écrire un post avec le smartphone, il me fait d'la Merde.

Pendant ma pause au taff, j'ai repensé à un truc au sujet des backups du serveur Craftbukkit...

Donc, j'ai remis en route hier soir un serveur Craftbukkit et un logiciel de Backup sur Linux pour détailler mon idée.

Craftbukkit à besoin d'un environnement d'execution java et pour fonctionner il a besoin d'une quantité de mémoire allouer à la machine. L'invocation de l'environnement est précédé de la quantité de mémoire que l'on a besoin en fonction de la quantité de joueur et la quantité de plugins que l'on veut installer.

Cette mémoire sert à l'environnement java, à être indépendant de la mémoire vive du reste de la machine, fonctionnent et travail avec elle comme dans une bulle.

Lorsque le serveur démarre, il consulte les propriétés du serveur ouvre le port puis charge en mémoire les plugins, identifie les mondes valide et charge les fichiers de configuration des plugins.

Les mondes sont reconnu, mais ne sont pas charger en mémoire. le serveur est en attente. Quand un joueur se connecte, il est identifié et est autorisé ou pas à y entrer: on dit qu'il dispose de droits en lecture/écriture sur le disque puis, une quantité de mémoire lui sera attribué.

Une fois le joueur connecté (l'utilisateur courant), ces paramètres en tant qu'utilisateur sont lu sur son fichier personnel et appliqués (position dans le jeu, son inventaire, sa vie etc...). Par sa présence sur un endroit de la map, le serveur charge en mémoire l'environnement pour ce joueur, lui envoi ses données et le joueur peut voir où il se trouve dans le jeu (c'est la lecture), la pose d'un bloc ou la casse d'un bloc (c'est l'écriture).

Une fois le chunk écrit en mémoire par l'utilisateur, les données vont être modifié en mémoire sur le serveur, plus des sauvegardes cycliques sont effectuées et c'est là à ce moment précis que commence le test.

j'ai réalisé au par-avant un backup du serveur à froid (éteint) pour comparaison, un backup en cour de route avant la sauvegarde physique et après en la forçant.

J'en conclu:

Warzouz a écrit:
Je reste persuadé que le principe de plugins est de couper la sauvegarde physique des fichiers de MC pendant le backup et de le réactiver ensuite.

Et c'est très juste!

Ghomerr a écrit:
Le plus sûr serait effectivement d'arrêter la sauvegarde pendant le backup pour s'assurer d'avoir la vision de la map à un instant t précis.

C'est la seul solution pour qu'un backup exterieur à Craftbukkit puisse aboutir sans qu'il existe des sauvegardes différés et il faut renseigner le logiciel de backup d'une ou des commandes à effectués avant le backup (qui d’ailleurs est une option de tout les logiciels de backup), avec "save-off" puis "save-all" comme on pourrait le faire manuellement.

Le code ci dessous montre l'action sur la sauvegardes avec une partie de script des liens d'un backup manuel que je gardais dans mon lanceur Minecraft.

Code:

mc_saveoff() {
if ps ax | grep -v grep | grep -v -i SCREEN | grep $SERVICE > /dev/null
then
echo "$SERVICE is running... suspending saves"
as_user "screen -p 0 -S craftbukkit -X eval 'stuff \"say SERVER BACKUP STARTING. Server going readonly...\"\015'"
as_user "screen -p 0 -S craftbukkit -X eval 'stuff \"save-off\"\015'"
as_user "screen -p 0 -S craftbukkit -X eval 'stuff \"save-all\"\015'"
sync
sleep 10
else
echo "$SERVICE was not running. Not suspending saves."
fi
}

mc_saveon() {
if ps ax | grep -v grep | grep -v -i SCREEN | grep $SERVICE > /dev/null
then
echo "$SERVICE is running... re-enabling saves"
as_user "screen -p 0 -S craftbukkit -X eval 'stuff \"save-on\"\015'"
as_user "screen -p 0 -S craftbukkit -X eval 'stuff \"say SERVER BACKUP ENDED. Server going read-write...\"\015'"
else
echo "$SERVICE was not running. Not resuming saves."
fi
}



Le logiciel de backup se base après sur une sauvegarde de référence puis compare les fichiers modifié postérieurement (sauvegarde incrémentielle) et les enregistre ne gardant que les fichier modifié dans une archive daté. Pour le compiler, le logiciel reprend la sauvegarde de référence et fusionne l'archive postérieur.

Après vous le faite en test ou pas, pour ma part je sais que cela fonctionne de cette manière là. si vous préférez un plugin spécifique maintenu à jour par vos soins il n'y a pas de soucis, c'est même préférable et plus saint pour l'administration concentré autour du craftbukkit et des ses plugins.

Merci pour cette analyse, Retro ;)

Du coup, pour résumer, soit on attend le plugin de Backup, soit on met en place ta solution avec un arrêt de la sauvegarde par appel à la commande minecraft "save-off" via un batch externe (celui que tu proposes par exemple, adapté à l'environnement du serveur).

Je n'ai pas eu de réponse de la part du développeur du plugin. Il est peut-être en vacances, par contre.

Edit: j'ai essayé de récupérer les sources du plugin Backup et de voir si je pouvais pas essayer de le mettre à jour mais il me manque une librairie pour faire fonctionner un truc en interne (protocole FTP) et pas moyen de mettre la main dessus... Ça fait une bonne demi-heure sinon plus que j'essaie et j'ai abandonné...

Pour info c'était le fichier "rt.jar" du package sun.net.ftp, classe FtpClient. Pas moyen de trouver la version utilisée dans le plugin disposant d'une fonction "connect()" qui prend en paramètre une variable de type "String", genre une "URL". Mon "rt.jar" dans mon environnement Java ne possède pas cette méthode

Bon, j'ai refait le point sur les plugins. Cela n'a pas beaucoup avancé. Il y a des versions de dev qui sont disponibles, ou des versions non officielles (notamment pour receipee manager)

Mise à jour du post. LWordEdit et worldGuard sont OK.

Merci Warzouz !
Vivement !

On a clairement un problème avec Recepee manager, le plugin n'est plus suivi. Quant à Backup, il y a des builds indépendantes qui semblent fonctionner.