Sauvegarder votre serveur OVH avec Borgmatic
Dans le précédent article de la série, j’explique comment utiliser borgmatic pour faire ses sauvegardes.
Dans cet article je vais expliquer comment faire les sauvegardes de son serveur dédié OVH en utilisant l’espace de sauvegarde (Backup Storage) de celui-ci.
Cet espace est un espace disque (généralement 500Go) qu’OVH mets à disposition de ses clients pour qu’ils puissent y faire leur sauvegardes. Nous allons dire à borgmatic d’y mettre les archives Borg.
Cet espace n’est pas accessible en SSH (il ne l’est qu’en FTP, *CIFS*/*SMB* et NFS). Dans le cadre d’un serveur Linux : NFS est le plus simple d’utilisation.
Vous pourriez très bien, si vous le préférez, utiliser un client FTP ou *CIFS*/*SMB* (en CLI ou via FUSE comme avec CurlFtpFS et SMB For Fuse.
Le service n’est pas activé par défaut, il faut l’activer manuellement via le Manager (ou l’API) d’OVH.
Je vous conseille de l’activer dès réception du serveur (sauf si vous savez que vous n’en aurez pas besoin) car il peut arriver qu’OVH soit en “manque de place” et ne puisse donc pas vous l’activer avant plusieurs jours.
Par défaut, OVH n’active que le protocole FTP, cela veut dire qu’il faut utiliser un client FTP pour accéder aux fichiers. Mais il est possible d’activer le CIFS (SMB)* et le NFS.
Le serveur CIFS/FTP/NFS d’OVH n’est pas joignable depuis Internet : il faut utiliser une des IPs de votre compte OVH. Mais cela veut dire que plusieurs serveurs dédiés peuvent utiliser le même espace Backup Storage.
Voici le lien vers la documentation du service : « Utiliser Backup Storage sur un serveur dédié (KB0043993) »
Préparation du serveur :
Activer le Backup Storage et récupérer les paramètres d’accès (envoyés par e-mail).
Activer le protocole NFS du Backup Storage (à faire une fois le Backup Storage activé par OVH)
Installation du package client NFS :
1
apt-get install --assume-yes nfs-common
Montage NFS simple (sans borgmatic)
La commande suivante permet de monter l’espace Backup Storage (via NFS donc) :
|
|
Voici un exemple complet :
|
|
Configuration de borgmatic
BorgBackup ne gère pas l’accès à un dépôt distant via NFS (il ne sait que faire du local ou du SSH), on va donc devoir monter le dossier pour lui.
Deux options :
- Vous monter le dossier distant NFS dès le démarrage du serveur
- Vous ne monter le dossier distant NFS que lorsqu’utilisé/nécessaire
La première option est simple (juste une ligne à rajouter dans /etc/fstab
) :
|
|
Mais elle peut être considérée comme instable (le serveur OVH de sauvegarde pourrait redémarrer ou sa connexion tomber temporairement) ou dangereuse (le dépôt est en permanence “connecté” à votre serveur) :
La deuxième option me semble plus sûre et peut être traitée de 3 façons :
- En faisant appel à
mount
avant d’exécuterborgmatic
dans votre script ou tâche cron qui effectue la sauvegarde. - Via Systemd-automount (ou AutoFS)
- Via borgmatic et son système de hooks
C’est cette dernière méthode que je vais utiliser.
Configuration de borgmatic pour sauvegarder sur Backup Storage OVH via NFS
Je pars du principe que :
- borgmatic est déjà installé et configuré.
- Le point de montage existe déjà et est :
/mnt/ovh_backup_storage
- Le nom du serveur OVH à sauvegarder (celui où tourne borgmatic) est :
ns0000000.ip-123-123-123.net
- Le nom du serveur OVH de l’espace distant Backup Storage est :
ftpback-rbx1-2345.ovh.net
On va modifier la configuration pour :
- Ajouter un dépôt situé sur les serveurs de sauvegarde d’OVH
- Gérer le montage/démontage NFS
|
|
Le hook d’avant (before_actions
) s’occupe de :
- Créer le point de montage si inexistant
- Monter le dossier distant via NFS si pas déjà monté
Le hook d’après (after_actions
) s’occupe de :
- Attrendre 5 secondes (histoire que borgmatic ait terminé)
- Regarde s’il n’existe bien aucun système de fichier de type FUSE et de source
borgfs (qui est le système de fichier que BorgBackup créer lorsqu’on
exécute la commande
borg mount
). Auquel cas il va vérifier que le point de montage est bien monté et le démonter le cas échéant.
Cette commande de démontage semble excessivement compliquée, et elle l’est,
mais c’est parce qu’elle gère l’action borgmatic mount
qui, avec une approche
simpliste faisait que borgmatic tentait de démonter le dossier dès que la
commande borgmatic mount
se terminait (alors que, au contraire, on voulait
qu’il reste monté, au moins jusqu’à l’appel de borgmatic umount
).
Une fois que borgmatic saura dire aux commandes/scripts appelé·e·s dans les hooks pour quelles actions borgmatic iels l’ont été (cf. cette issue en cours que je n’ai pas, à ce jour, résolue) elle pourra être grandement simplifiée.
Si vous aimez le contenu, vous pouvez aider
Sponsor