Je dispose de plusieurs sites Internet qui sont hébergés chez différents fournisseurs. Pour certain, j’opère la machine virtuelle et sa configuration tandis que dans d’autres cas il s’agit d’un hébergement clé en mains. La plupart du temps la société propose une solution de sauvegarde intégrée. Mais dans certains cas, il peut arriver que le datacenter de la société prenne feu et qu’on nous annonce que les backups étaient effectués au même endroit… Du coup, je ne saurais que trop vous conseiller de prendre le temps de vous assurer de faire une sauvegarde par vous-même. 🔥
Dans cet article, je vous propose de voir comment on peut sauvegarder rapidement et facilement son site Internet directement sur un Storage Account (STA) dans Azure. L’intérêt de ce service et qu’il vous offre un espace de stockage presque illimité avec la possibilité d’avoir plusieurs copies dans les différents datacenters de Microsoft.
Etape 0 – Installation des prérequis
Création d’une machine virtuelle Linux
Vous pourriez utiliser n’importe quel OS mais moi je vais prendre une Ubuntu LTS pour être tranquille plus longtemps. En termes de configuration, j’ai choisi une Standard B2s (2 vcpus, 4 GiB memory) mais vous pourriez prendre quelque-chose d’encore plus petit. Configurez également votre login/password ou clé SSH et connectez-vous à votre nouvelle VM.
Création d’un Storage Account dans Azure
Pour la création de votre STA, vous pouvez globalement garder les options par défaut. Je vous encourage à prendre un v2 afin d’être tranquille plus longtemps : general purpose v2 en performance standard. Au niveau du mode de réplication, j’ai choisi d’utiliser LRS – stockage localement redondant qui est suffisant pour moi puisque c’est déjà une sauvegarde et je cherche une solution optimisée en termes de coût.
Dans la même idée, je vous encourage à choisir le default access tier à Cold. C’est très important car nous n’allons pas vraiment accéder aux données de manière régulière – cette sauvegarde doit nous servir uniquement « en cas de besoin ». En configuration en Cold, nous allons faire descendre de beaucoup le prix de stockage des données. N’oubliez donc pas cette option.
Création d’une file hare dans votre STA
Dans votre Storage Account, allez dans l’option File-shares et créez un nouvel espace de stockage. Donnez-lui le petit de nom de votre choix et surtout choisissez l’option Tier: Cool.
Etape 1 – Connexion de votre file share à votre VM Linux
Pour ce faire, utilisez directement le bouton Connect disponible au niveau de votre file share. Dans l’onglet Linux, vous allez retrouver un court script qui est déjà prêt à l’emploi. Copiez le contenu de ce script dans un fichier sur votre VM Linux avec votre éditeur favoris (dans mon cas nano) et donnez-lui les permissions de s’exécuter.
chmod +x mountSTA.sh
Ensuite, vous pouvez exécuter le script (voir même le mettre en démarrage automatique dans votre fichier crontab). C’est ce que j’ai fait pour ma part.
Si tout se passe bien, vous verrez un nouveau point de montage disponible sur votre VM Linux. Il aura une taille de 5 TB donc vous aurez de la marge pour backup votre site Internet. 🙂
Etape 2 – Backup votre site
Ensuite, l’idée est simple : j’ai créé une clé SSH sur ma VM afin qu’elle puisse se connecter en 1 clic à mon hébergement chez OVH, Online.net, Infomaniak ou autre.
Une fois connecté, je créé une archive compressée de l’ensemble des fichiers de mon site Internet avec les quelques lignes ci-dessous :
#!/bin/bash
# Date
d=$(date +%Y-%m-%d_%H-%M)
# Export de la BDD
mysqldump --no-create-db=true -server' -u'login' -p'password' database > /home/user/backups/"$d"_sql_backup_blog.sql
# Making the tar.gz for all the files
tar -czvf /home/user/backups/"$d"_backup_blog.tar.gz /home/user/public_html/*
Cela aura pour effet de générer 2 fichiers :
- Un export du contenu de la base de données SQL (remplacez le login, password et database par les informations de votre site Internet). Si besoin, vous pouvez retrouver ces informations dans votre fichier wp-config.php.
- Un fichier .tar.gz avec la date et l’heure qu’il était au moment de la génération. Pratique si l’on souhaite faire plusieurs backups par jour. Il contient l’ensemble des fichiers de mon site : images, fichiers PHP, etc.
J’obtiens quelque-chose comme ça :
Une fois que j’ai mes fichiers, je n’ai plus qu’à les rapatrier depuis mon hébergement vers ma VM dans Azure directement dans le dossier de mon Storage Account. Perso, j’ai utilisé la commande suivante :
scp ovh:/home/clients/user/perso-backup/* /mnt/infomaniak/
Attention, pour que ça marche cela suppose que vous avez créé une clé SSH pour que votre VM puisse se connecter à votre hébergement. Vous aurez également créé un fichier config dans votre dossier .ssh pour que le termes « ovh » soit reconnu (c’est un exemple).
Tous mes fichiers backups sont donc récupérés et copiés directement dans mon dossier /mnt/infomaniak qui correspond au nom du file share que j’ai créé sur mon Storage Account.
A ce moment-là, ma sauvegarde est terminée ! 👍
Si je positionne ces quelques lignes dans un script que j’exécute via mon crontab, alors je suis en capacité de faire un backup automatisé chaque jour de mon site Internet. Dans ce cas, après quelques jours de fonctionnement vous devriez voir quelque-chose similaire à la capture d’écran ci-dessous dans votre Storage Account via le portail Azure :
Etape 3 – Combien ça coûte ?
Et bien c’est là que c’est intéressant… 🤑
L’ensemble du process va me coûter moins de 15 € / mois pour l’ensemble des ressources que j’ai choisi d’utiliser dans Azure. En effet, je laisse la VM fonctionner moins de 30 mins chaque jour le temps de faire le backup (je pourrais encore optimiser). Et surtout, le Storage Account est configuré en Cold – autrement dit tant que je n’accède pas ou ne télécharge pas les données… le prix est anecdotique.
Considérant que je dispose d’une souscription Azure de 130 $ renouvelée chaque mois automatiquement grâce à mon status de MCT (Microsoft Certified Trainer) – et bien on peut considérer que c’est gratuit (et il me reste encore du crédit pour faire autre chose).
Alors évidemment, ce n’est pas la seule solution. C’est 1 solution et il en existe plein pour ce type de besoin. Idéalement, la prochaine étape serait de faire du serverless à la place de ma VM mais je ne suis pas encore assez expérimenté là-dessus (un prochain article sans aucun doute). 😉
