Si vous perdez les données de votre jeu web, vous risquez d’être totalement démotivé: à quoi bon refaire ce jeu que vous avez perdu? Et même si vous êtes motivé, réussirez-vous à refaire un jeu aussi bon? Je suis passé par là quand j’ai développé ECLERD v0, il y a près de 10 ans: l’un de mes disques dur avait lâché, et j’avais perdu mon jeu du jour au lendemain… Quelle déprime! Comment éviter cela?

De quelles données parle-t-on?

Les données de dev

D’abord, clarifions un peu ce qui se cache derrière le mot “données”, histoire de savoir si cet article vous est vraiment destiné. Derrière ce terme très générique, je place en pratique tout ce qui sert à créer votre jeu web: les sources du jeu déjà sorties, mais aussi les sources en cours de développement, les données de test, les plans de conception, les artworks, et l’ensemble de l’écosystème de développement qui va autour de votre jeu (votre configuration locale et vos préférences d’IDE par exemple). Il ne s’agit donc pas de préserver les données de production du jeu (ce qui est du ressort de l’hébergeur, auquel je ne m’adresse pas dans cet article) mais d’être capable de remettre en place votre environnement de développement (votre environnement de travail) même après une panne matérielle ou une perte de données quelconque (ransomware).

Je ne vous parlerai donc pas de comment gérer vos backups de production. Nous allons plutôt nous intéresser aux backups de développement, qui sont indispensables chez les développeurs hobbyistes mais trop souvent oubliés voire ignorés.

Exemple: la perte des données d’ECLERD

J’ai commencé le développement d’ECLERD il y a près de 10 ans. Ce développement m’avais pris, à l’époque, quelques 3-4 mois, quand boom! L’un de mes disques durs a grillé… Perdre autant de travail d’un coup fut très difficile à endurer, et même si j’avais trouvé, à l’époque, le courage de recommencer le jeu de zéro, je ne suis pas sûr que j’aurai de nouveau ce courage si cet évènement survenait encore.

Récupérer ses données

Du coup, après cette perte, je me suis intéressé de près aux solutions de récupération des données. Il en existe pas mal, dont la plus radicale consiste à lire directement le contenu brut du disque dur, et essayer de retrouver les données des fichiers perdus. Mais, si cette méthode est très enrichissante pour comprendre le fonctionnement d’un système de fichier et d’un disque dur, elle n’est ni fiable, ni efficace. Préparez-vous à passer des jours (vraiment!) pour finalement récupérer à peine 20% de votre travail, et 80% de choses inutiles que vous n’aurez jamais le courage de trier. Mieux vaut donc prévenir la perte de données que la guérir.

C’est l’un des rares cas où l’anticipation vaut mieux que l’adaptation.

Compter sur l’hébergeur

Certains créateurs de jeu que je connais se reposent uniquement sur leur hébergeur pour éviter la perte de données: comme leur jeu web se trouve sur un serveur web, ils se considèrent comme “à l’abri” de toute perte de données. Toutefois, ces données ne concernent alors que l’état du jeu public et à l’heure actuelle: quid des documents de conception de votre jeu? De l’historique des modifications de vos sources? De la fonctionnalité que vous êtes en train de développer depuis 2 mois, et qui n’est pas encore en ligne car pas encore terminée? Et si l’hébergeur fait faillite? Pour toutes ces raisons, l’hébergeur web ne suffit pas pour palier à la perte de données.

Les “données” de votre jeu web ne sont pas juste le contenu de votre BDD en prod (l’hébergeur se charge de les gérer, et c’est bien assez compliqué pour ne pas vous éparpiller là dessus), mais aussi vos codes sources, les raisons pour lesquelles vous avez codé telle ou telle feature, les images de votre jeu, la structure de votre BDD, vos notes persos, etc.

Un hébergeur comme OVH a peu de risques de faire faillite, mais vous pouvez faire un régulier de vos bases de données et du contenu de votre serveur FTP, histoire d’avoir une roue de secours en cas de pépin. Chez OVH, le de la BDD d’un hébergeur mutualisé (ou d’un Private SQL) peut être téléchargé depuis votre manager.

Copier ses données

La meilleure façon de se protéger de ce genre de perte consiste à copier ses données. Au début, je le faisait manuellement, en copiant le dossier de développement de mon jeu sur un support amovible… Mais ce n’est vraiment pas pratique! Alors, pour gagner du temps, j’ai mis des scripts en place.

Avoir au moins 2 copies de votre jeu web est capital: sans cela, vous pouvez TOUT perdre du jour au lendemain, sans aucun possibilité de revenir en arrière!

L’un des logiciels que j’utilise maintenant pour faire ces copies est Free File Sync. Il permet de synchroniser des dossiers ou des disques durs/clefs USB, un peu comme le “Porte-Documents” de Windows le fait, mais avec bien plus d’options et de facilités. Je vous recommande donc de l’installer, puis de suivre les étapes ci-dessous pour mettre un backup en place. En cas de perte de données, vous aurez alors la possibilité de récupérer ces données depuis ce backup. Vous n’aurez rien perdu (ou juste les données entre le moment où vous avez mis à jour votre backup, et le moment où vous avez perdu vos données, ce délais étant souvent assez court pour être acceptable).

Utilisation

Comparer le dossier original et sa copie

L’utilisation est on ne peut plus simple: lancez le logiciel, choisissez le dossier-source (le dossier de gauche, coté “bleu”), choisissez la destination (le dossier de droite, coté “vert”), puis cliquez sur “Comparer”.

Capture d'écran de Free File Sync
Free File Sync compare les deux dossiers

Une fois l’analyse effectuée, un symbole au centre vous indique l’action qui sera à faire:

  • Un signe égal “=” pour un fichier identique entre les deux dossiers (même chemin relatif, même nom, même contenu): ce fichier ne sera pas copié, pour gagner du temps
  • Une flèche vers la droite “→” pour un nouveau fichier: il sera copié de la gauche (original) à la droite (copie)
  • Une corbeille pour les fichiers de droite (copie) qui ne se trouvent plus à gauche (original): ils seront supprimés de la copie
Mettre à jour la copie

Il ne vous reste alors plus qu’à cliquer sur “Miroir”, en haut à droite, pour lancer l’archivage. L’avantage de Free File Sync par rapport à une copie “à la main” (vous copiez votre dossier de projets depuis votre ordinateur vers le support amovible servant d’archive) réside dans l’incrémentation de la copie: seuls les fichiers ajoutés/supprimés/modifiés seront recopiés. Les autres resteront inchangés. La duplication de votre dossier de projet sera donc plus rapide.

Copie en cours
Copie en cours…

La copie terminée, vous voilà avec un dossier sur votre clef USB/disque dur externe identique à votre dossier de travail. En cas de défaillance mécanique (ordinateur qui ne démarre pas, disque dur grillé,…), vous aurez une copie de votre projet sur votre clef. Si vous le souhaitez et avec la même démarche, vous pouvez copier toutes les données de votre ordinateur (le disque dur entier).

Automatiser la copie

Faire cette manipulation à la main toutes les 2 semaines (ou plus souvent encore) pour mettre à jour votre backup est fastidieux. Pour éviter cela, vous pouvez sauvegarder votre “projet” via Fichier/Enregistrer. Vous obtenez alors un fichier ffs_batch, contenant le descriptif de votre backup (la liste des dossiers source à copier, l’endroit où les copier, et la règle de mise à jour à appliquer [Mirroir]). Vous n’aurez plus qu’à double-cliquer ce fichier pour que Free File Sync l’exécute et mette votre backup à jour.

Ce fichier ffs_batch est un fichier au format XML: vous pouvez l’ouvrir et l’éditer avec Notepad++. Je vous conseille également de backuper ce fichier, pour savoir quel dossier a été sauvegardé à quel endroit dans votre backup.

Vous pouvez d’ailleurs lancer ce fichier automatiquement, en créant une tâche planifiée dans Windows. Personnellement, je ne le conseille pas, car votre backup doit être sur un support amovible, que vous devez débrancher après chaque backup (sinon, un coup de foudre sur votre maison pourrait vous faire tout perdre, backup inclus!). Comme le branchement/débranchement de ce backup est manuel, l’opération de mise à jour peut l’être aussi. Je vous recommande de la faire toutes les semaines (en gros) et de bien débrancher votre backup du secteur (s’il possède un transfo 220V) et de le débrancher aussi de votre ordinateur après chaque mise à jour. Enfin, ayez 2 backups si possible: un backup complet de vos données, qui peut être mis à jour “peu souvent” (2x par mois en gros) et un backup de vos données critiques (papiers administratifs, codes de vos jeux web, etc) que vous mettez à jour 2 ou 3 fois par semaine (après chaque séance de développement).

Principe

Le défaut de Free File Sync est de nécessiter autant d’espace que vous avez de données à copier. Si, comme moi, vous avez 8 disques durs dans votre tour d’ordinateur, alors vous aurez du mal à trouver assez de place pour tout copier… Une solution consiste alors à émuler un RAID, c’est à dire à copier, sur un 9e disque, la parité des 8 autres. Cela signifie que vous allez ajouter un 9e disque dur qui contiendra une “redondance” des 8 autres sous forme de parité: le 1er bit de ce 9e disque dur sera 0 si la somme du 1er bit des 8 disques dur est paire, et 1 si elle est impaire. Grâce à cela, si l’un des 8 disques dur casse (peu importe lequel: c’est là qu’est la force d’un RAID!), il vous sera possible de le remplacer par un disque dur neuf, vide, et de reconstruire le contenu du disque cassé à partir des 7 autres disques encore valides et du disque de parité.

Ce 9e disque de parité permet de restaurer n’importe lequel des 8 autres. Donc, avec 1 seul disque supplémentaire, vous protégez les 8 disques que vous possédez déjà!

La configuration

Installez SnapRAID puis ouvrez le fichier de configuration qu’il fournit par défaut. Modifiez-le pour indiquer les disques à backuper (si vous n’avez qu’un seul disque dur, SnapRAID ne servira à rien), et les partitions associées. Ne backupez ainsi qu’une seule partition par disque maximum! Indiquez enfin la lettre de lecteur du disque qui contiendra la parité des autres (ce fichier de parité doit être sur un disque dur physique différent, sinon, SnapRAID sera inutile en cas de panne matérielle).

Si vous avez plusieurs partitions sur un même disque dur, alors ne backupez qu’une seule de ces partitions. Si vous voulez backuper plusieurs partitions d’un même disque, alors vous devrez avoir autant de fichiers de parité que de partitions sur ce disque. Je ne vous le recommande pas: c’est compliqué pour rien.

Si 1 disque physique possède 3 partitions, le perdre fait perdre 3 partitions: il faut donc 3 fichiers de parité.
Nombre de fichiers de parité >= MAX(nombre de partition sur chaque disque)
# Fichier de parité.
# Il ne doit PAS être sur l'un des disques de données que vous sauvegardez
parity I:\snapraid.parity

# Fichier listant les fichiers de données qui seront backupés
# Au moins 1 par ligne "parity", +1 autre de plus
# Donc pour moi, 2 fichiers suffisent (j'en ai mis 4, juste comme ça!)
content E:\Programs Data\snapRAID\snapraid.content
content C:\snapraid.content
content J:\snapraid.content
content I:\snapraid.content

# Les partitions de données à backuper
# Il est possible d'utiliser les volumes virtuels de windows
# qui permettent de faire passer un dossier pour un disque dur.
disk MesCreas E:\
disk Biens F:\
disk TVRecords H:\
disk Moyens J:\

# Ne pas backuper les fichiers cachés
nohidden

# Exclure certaines extensions et certains dossiers
exclude *.unrecoverable
exclude Thumbs.db
exclude \$RECYCLE.BIN
exclude \System Volume Information
Ma configuration SnapRAID; n’hésitez pas à en avoir une copie de secours!

Raccourcis

Enfin, créez un raccourci sur le bureau qui lancera ce backup. Vous devrez ouvrir ce raccourci régulièrement, pour assurer un backup hebdomadaire de vos données. Vous pouvez intégrer le lancement de ce raccourci au planificateur de tâches de Windows, comme pour Free File Sync. En revanche, SnapRAID ne peut restaurer un disque dur à partir du disque de parité que si un et un seul disque dur est en panne. Si deux disques ou plus sont morts (parce que la foudre a flingué votre tour en totalité), alors SnapRAID est inutile. Donc, vous pouvez utiliser un disque dur interne de votre tour comme disque de parité, et le laisser brancher en continu. Lancer automatiquement la mise à jour du backup peut alors être intéressant.

C:\Windows\System32\cmd.exe /c "L:\snapRAID\snapraid.exe --force-zero sync & pause"
Mon raccourcis pour lancer SnapRAID

Restauration

Pour Free File Sync, la restauration est simple: vous branchez votre backup et vous copiez vos données depuis ce backup vers votre PC. Pour SnapRAID, c’est plus complexe. Supposons qu’une panne d’un des disques dur est survenue. Vous devez d’abord remplacer le matériel défectueux (s’il l’est, sinon, formatez-le pour le remettre à zéro). Ensuite, créez une nouvelle partition vide sur ce disque pour restaurer les données. Cette partition doit être au moins aussi grande que la partition de données perdue. Attribuez-lui la même lettre de lecteur (ie: H:) et le même nom de lecteur (ie: TVRecords) que la partition de données perdue (c’est important pour simplifier la restauration). Il ne vous reste plus qu’à lancer la commande de restauration de SnapRAID. L’opération peut prendre des heures. Une fois terminée, vous devrez lancer la commande de vérification, pour vous assurer qu’il n’y a pas eu de pépin (elle peut être tout aussi longue!).

snapraid -d "Ma partition" -l restauration.log fix
snapraid -d "Ma partition" -a check
Commande de restauration et commande de vérification

Je vous recommande de vous entraîner à cela dès maintenant, avec des clefs USB ou des lecteurs virtuels. Cela vous permettra d’être prêt le jour où une vraie panne surviendra. Si vous avez le moindre problème avec SnapRAID, n’hésitez pas à consulter le manuel, la FAQ ou le forum.

Le backup “dans le temps”

Tous ces backups sont pratiques pour récupérer vos données après une perte sèche. Mais un autre type de perte de données peut survenir. Imaginez que vous vous lancez dans le développement d’une grosse fonctionnalité de votre jeu. Après 2 semaines de dev et alors qu’elle n’est qu’à moitié finie, vous vous apercevez qu’elle n’est pas intéressante et que la développer était une mauvaise idée. Qu’allez-vous faire? Comment allez-vous réussir à “annuler” ces modifications? Eventuellement, vous pourriez faire une copie de votre jeu avant de coder une fonctionnalité, et restaurer cette copie, mais cette solution est fastidieuse! De plus, supposez que vous développez vraiment la feature, vous la mettez en ligne, et après 2 semaines, vos joueurs vous remontent plein de bugs ou vous font savoir qu’elle gâche le jeu: comment allez-vous faire pour la retirer?

Ce problème se rencontre aussi quand vous avez écrit un code 3 mois plus tôt, et que vous le relisez aujourd’hui en vous demandant “mais pourquoi j’ai fait ce code?”

On a vu que la solution de copier votre jeu avant de développer une feature est… chiante. Mais il existe un logiciel qui peut l’automatiser: Areca. Son principe est similaire à Free File Sync, l’historisation en plus: au lieu de copier les fichiers sur le backup et d’écraser les anciennes versions, Areca met de côté une copie du fichier du backup avant de l’écraser. Vous avez donc la possibilité de “revenir en arrière”. Mais il faut, là encore, lancer ce backup à la main avant de commencer une feature…

Le avec

Une solution existe en fait depuis des décennies: le versionning. Son principe est très proche d’Areca: vous avez un dossier de travail (le dossier de votre jeu web), vous en modifiez le contenu, puis vous indiquez au logiciel de versionning que vous avez terminé votre travail (cela s’appelle “commiter”) et vous lui décrivez pourquoi vous avez fait ces modifications (c’est le “commit message”). Le logiciel va alors enregistrer ces informations dans un sous-dossier dédié. Dès lors, vous disposez d’un historique de toutes les modifications de votre projet, avec la raison pour laquelle vous aviez fait chacune d’entre elles.

Il existe plusieurs logiciels de versionning, les plus connus étant et Mercurial. Personnellement, j’ai choisi Mercurial, que je trouve un peu plus simple surtout quant vous installez un logiciel graphique comme TortoiseHg pour le gérer.Enfin, comme Git, Mercurial peut s’intégrer à votre logiciel de code (votre IDE) pour vous faciliter la tâche.

La vue de TortoiseHg, pour gérer Mercurial L'intégration de Mercurial dans IntelliJ
Mercurial via TortoiseHg, et son intégration dans l’IDE (IntelliJ) qui vous permet de voir directement quelles lignes ont été modifiées (bleu), supprimées (rouge) ou ajoutées (vert) depuis votre dernier commit

Mercurial (ou Git) stockent leurs informations dans un sous-dossier de votre jeu web: il sont donc tout à fait compatibles avec SnapRaid et Free File Sync: ces derniers considèreront le sous-dossier de Mercurial comme un dossier classique, et le backuperont de la même façon.

Au final…

Backuper vos sources en intégralité est capital. Vous devez être capable de retrouver rapidement votre environnement de développement si jamais un de vos disques dur grillait. Mercurial, Free File Sync et SnapRAID sont de bons outils pour cela. N’hésitez pas à faire de la redondance et avoir plusieurs backups.

Pour ma part, j’ai un backup SnapRAID de toutes mes données, un autre backup de toutes mes données via Free File Sync, et deux backups Free File Sync de mes données critiques (jeux web, documents administratifs, photos persos, etc). Je les mets à jour de manière désynchronisées: en cas de problème (données vérolées), les anciens backups sont encore fiables.