Mon blog tourne sur un serveur virtuel extrêmement cheapos chez OVH, qui sont par ailleurs connus pour les datacenters qui crâment et votre serveur qui est tout à coup réinstallé voire la migration en 1-click qui en fait dure 24h et se débloque avec un ticket de support.
En vrai j'ai (étrangement) jamais vraiment eu de problème avec mon serveur. Une ou trois grosses pannes réseau et quelques petites mais pas de gros effacement forcé par exemple. Chouette hein.
Je dis ça mais OVH ils te disent bien dans leur FAQ (voire dans l'espace client, je sais plus où j'avais vu ça) qu'il faut que tu fasses des backups. Non sérieusement, backup ton truc. Ils te donnent même un espace de backup pseudo gratuit dans certaines offres (qui brûle générallement avec le datacenter donc faites attention).
J'avais un super plan à base de SCRIPT PERL pour envoyer mes données sur un Google Drive, qui en plus gardait plusieurs versions des fichiers.
C'était plutôt cool jusqu'à ce je réinstalle le VPS pour enfin mettre tout mon merdier à jour (c'était une Debian 8, on est à 12) où je me rend compte que même en recopiant bien tous mes répertoires cachés de token Google et l'ancienne version du programme, ben ça marche plus. On me dit que je suis pas autorisé à modifier ce drive.
L'utilitaire gdrive
J'utilisais un utilitaire trouvé sur Github, qui apparemment n'est plus maintenu. Il existe cependant un fork ici: https://github.com/glotlabs/gdrive
Je suis plein d'espoir. Jusqu'à ce que je découvre ce qu'il faut faire pour connecter l'utilitaire à son drive.
Petit extrait de leur doc:

Et ils ne plaisantent pas ce processus est horriblement complexe.
Sans compter que ces étapes ne sont même plus vraiment d'actualité. Google a réussi à changer encore plus de trucs dans une suite d'interfaces disjointes qui te forcent à remettre en question ta place dans l'univers.
Tu te sens comme dans un labirinthe créé par les délires fiévreux de vapeurs de Bush Ambrée chaude où tu crées un "projet" mais après il faut créer une app, puis un "écran de consentement" (???)

La justification pour tout ce jeu de piste c'est la "sécurité". Ben ouais. On va pas avoir l'esprit un peu conspirationniste et se dire qu'ils voulaient juste qu'on évite d'utiliser Google Drive de manière programmat... Programmatique? Programmée. Avec un programme.
Soit, de toutes façons ça marche pas. J'ai jamais réussi à être autorisé.
Utilisons rclone, à l'arrache
Il y a un autre projet pas si récent, rclone, qui permet de copier des fichiers sur toute une série de fournisseurs cloud différents.
L'utilitaire peut se configurer de manière interactive en ajoutant des "remotes" qui sont les différentes destinations de copie à utiliser.
La config interactive c'est simplement:
rclone config
J'ai d'abord essayé avec Proton Drive tant qu'à faire, pour rester pseudo-européen.
Il faut utiliser la version Beta et dans mon cas je me retrouvais avec une copie qui ne se termine jamais. Bon. Je retire la version beta et j'utilise le rclone qui est dans les paquets Debian:
apt install rclone
Puis ben... Je vais utiliser OneDrive de Microsoft. Au point où on en est. Je pourrai toujours changer plus tard.
Dans l'assistant de config mentionné plus haut, je crée un nouveau "remote".
Rclone propose de créer un petit serveur et lancer le navigateur pour récupérer le jeton d'authentification pour vous le plus simplement possible, et ça, c'est cool.
Sauf que je suis sur un serveur sans interface graphique, y a pas de navigateur. C'est pas grave, j'utilise une redirection SSH depuis ma machine:
ssh -L 53682:localhost:53682 <VOTRE_UTILISATEUR>@<SERVER>
Vous pouvez ensuite visiter la page depuis votre machine sur http://127.0.0.1:53682/.
Je conseille vraiment d'utiliser cette technique parce que sinon vous êtes partis sur le portail Azure pour du bon gros fun.
Le script
Cette fois-ci j'ai abandonné le PERL pour du bon vieux Bash et pondu ce truc en 4 minutes:
#!/bin/bash
BACKUP_SOURCES="/srv/
/etc/nginx/
/etc/nftables.conf
/etc/postfix/
/etc/systemd/system/
/home/mailuser/"
# <RCLONE_REMOTE>:<BACKUP_DIR>
# No trailing slash!
RCLONE_DEST="onedrive:/vps"
for s in $BACKUP_SOURCES; do
if ! rclone sync -l "$s" "${RCLONE_DEST}/${s}"
then
echo "backup sync error for ${s}"
fi
done
Bon c'est juste une bête mono-synchro (efface aussi les fichiers qui ont disparu de la source dans la destination) que je programme une fois par jour.
Avant j'avais 15GB (5GB avec OneDrive et pratiquement tous les autres concurrents d'ailleurs) et plusieurs versions.
J'ai pensé à plusieurs plans semi-pourris d'évolution quand j'étais sur les WC ce midi:
- Avoir deux ou trois espaces cloud chez des fournisseurs différents et copier sur l'un ou l'autre tour à tour de sorte à avoir deux ou trois jours de backups et une synchro multi-cloud en bonus (ça a l'air malin mais c'est un peu nul lol);
- Céer plusieurs répertoires et une logique de rotation pour garder plusieurs versions du backup complet — J'ai pas vraiment la place pour avoir plusieurs copires complètes.
Reste le plan du backup incrémental homemade en utilisant par exemple la commande find de Linux pour sélectionner les fichiers qui ont changé depuis le dernier backup et copier uniquement ceux-là dans le "répertoire du jour". De temps en temps il s'agit de recréer un backup complet qui sera nécessaire pour restaurer la totalité (d'abord le backup complet puis l'incrémental au dessus). Si vous avez rien compris c'est pas grave je vais même pas relire ce paragraphe.
On verra tout ça pour un futur article moins à l'arrache.
Je vous livre un autre conseil gratuit de professionnel de l'opérationnel: c'est une bonne idée d'avoir un système qui vous alerte en cas d'erreur sur le backup — Sinon le jour où vous en avez besoin, en général, vous découvrez que le dernier backup date de 1970.
Cron peut être configuré pour envoyer des emails à une adresse externe en cas sortie d'erreur sur une tâche planifiée.
Commentaires
Il faut JavaScript activé pour écrire des commentaires ici
#1
#2