Composant PHP de sauvegarde de sites web

Contexte

J’avais besoin depuis un moment de packager un composant PHP qui me permette de sauvegarder rapidement et sûrement les sites que je réalise. Les objectifs étaient les suivants :

• exécution en ligne de commande (approche automatisable)
• grande configurabilité (ajout de sites, backup medias…)
• approche basée sur Composer (PHAR, auto-update)

J’ai donc développé websites-backup. Les détails sont ci-dessous.

Utilisation du composant

À l’aide d’un fichier de configuration YAML, vous pouvez définir :

• Plusieurs sites à sauvegarder (présents physiquement sur le serveur et accessibles par l’utilisateur système de la commande) : chaque site est composé d’un couple databases/fichiers (seulement MySQL pour le moment)
• Plusieurs backup medias : à ce stade, seul FTP est développé. À terme, j’aimerais mettre en place une passerelle Amazon et Dropbox. L’objectif ici est clairement de permettre plusieurs storages simultanés et synchronisés.

Note : d’un point de vue sécurité, je recommande de créer un utilisateur système par site, avec des droits en lecture seule.

Basé sur des components Symfony…

J’ai utilisé ce projet comme terrain d’entraînement pour n’utiliser que quelques components Symfony. De mon point de vue, c’est une très bonne manière de les prendre en main pour de vrai et de se concentrer sur leurs périmètres et leurs limitations. Un rapide coup d’œil à composer.json donne la liste des components :

• Console component : il fournit l’approche et les outils en ligne de commande. Arguments, options, console styling…
• Config component : il apporte la gestion de configuration, avec des méthodes chaînées puissantes pour vérifier et décider quoi faire des valeurs de configuration transmises à l’application.
• YAML component : le parser YAML, utile pour lire le fichier de configuration cité au-dessus.

…Mais pas seulement

Pour renforcer l’application du point de vue usage et maintenance, j’utilise aussi quelques packages :

• The excellent Box : permet de créer un PHAR configurable en un rien de temps.
• Phar update (ancien mais toujours fonctionnel) : avec un système de manifest, il fournit la logique nécessaire pour vérifier l’existence de nouvelles versions et mettre à jour si besoin.

Voici le process que je suis :

1. Faire les mises à jour (code, README…) qui feront partie de la future release
2. Commiter les changements et créer un tag cohérent (par exemple : 1.0.13)
3. Packager l’application avec Box
4. Publier l’archive et le manifest de mise à jour sur GitHub pages (branche gh-pages)

Au prochain lancement, l’application décide, à partir du manifest, si une version plus récente est disponible (comparaison numérique des versions, d’où l’intérêt d’un tagging cohérent et séquentiel). La commande self-update met alors effectivement l’application à jour.

Aussi

Étant donné que plusieurs commandes sont disponibles via websites-backup, j’ai choisi Pimple pour disposer d’un container d’injection de dépendances simple mais puissant. Je peux instancier les dépendances au point d’entrée principal de l’application :

$container = new Container();
$container['tools'] = new BackupTools();

Puis passer le container à toutes les commandes :

$application->add(new Command\BackupCommand('backup', $container));
$application->add(new Command\RetrieveBackupCommand('retrieve', $container));

Roadmap

OK, ça fonctionne, mais il y a de nombreuses fonctionnalités et améliorations que je souhaite ajouter. Si le projet vous intéresse et que vous souhaitez donner un coup de main, n’hésitez pas à me contacter !