Pont HTTP pour FTP vers Dedibackup

Souci de backup : je ne peux plus récupérer mes archives stockées sur un Dedibackup directement par FTP pour en avoir une copie locale, et accessoirement les valider. Sur ce dernier sujet voir l'article Validation de backups daté d'avril 2008.

Les serveurs Dedibackup sont des espaces FTP accessibles depuis les serveurs dédiés Dedibox, et jusqu'à il y a quelques mois ils étaient également accessibles en download par l'extérieur. Il suffisait de sécuriser ça en n'acceptant que certaines IP appelantes.

J'utilisais donc ce système pour avoir une machine locale « bkp » qui allait chercher régulièrement ce que déposaient tout aussi régulièrement sur mon espace Dedibackup deux Dedibox « ref1 » et « ref2 ».

Pas de bol, donc, Dedibox a coupé l'accès extérieur :

Comment résoudre ça au plus vite ? J'ai fait un service web ad hoc qui délègue ensuite au FTP,  pour « contourner » le problème comme on le voit :

Le gros du boulot a consisté à bétonner le fonctionnement du client FTP embarqué dans la webapp J2EE, elle-même bien bridée (une seule exécution à la fois, etc.). Les choix d'architecture n'étant pas vraiment conformes à la norme et donc n'apportant aucune garantie, « bétonner » signifie ici développer des tests d'intégration sur des chaînes un peu trapues. Au total avant d'être déployé, le système a été validé sur 3 environnements différents, dont un d'intégration continue.

Le tout a été conçu en une journée (elapse) et développé en une journée (load). Le développement a été concentré (focus), donc en tout on a un elapse de deux jours, et c'est tant mieux puisqu'après c'étaient les fêtes. Comme les backups sont un point crucial de la chaîne du SI, et sont en même temps totalement éloignés du métier, il était important de se sortir de cette charge le plus vite possible. Il ne reste qu'à mener des tests de performances et avoir des chiffres pour le futur suivi des évolutions.

Je dégage de cette histoire deux enseignements :

1. c'est justement parce que certaines choses importantes ne font pas partie à proprement parler du métier qu'il faut absolument s'en occuper sérieusement, éliminer toutes les frictions et perdre le moins de temps et d'argent possible sur elles.
2. une architecture technique pourrave est parfaitement acceptable (en fait je m'attends même à ce qu'elle tienne la durée) si par ailleurs les cas d'utilisation sont encadrés : en l'occurrence ceinture et bretelle par des tests en continu.

Le premier point incite au discernement quant à notre cœur de métier et pousse logiquement aux actions-force quand il y a besoin plutôt que d'accepter des demi-mesures qui laissent ouverts les problèmes périphériques. Pour atteindre le centre est nécessaire que la périphérie ne soit plus un problème |-)

Le deuxième point incite à un dilettantisme de bon aloi ; et en même temps qui sait rendre des comptes.

Let it go.