Sauvegarder votre serveur OVH avec Borgmatic

Séries - Sauvegarde via BorgBackup

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.

Notes sur le *Backup Storage*

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) »

  • 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
    

La commande suivante permet de monter l’espace Backup Storage (via NFS donc) :

1
2
3
4
mount \
    -t nfs \
    ${NOM_SERVEUR_BACKUPSTORAGE}:/export/ftpbackup/${NOM_DU_SERVEUR_OVH} \
    "${POINT_DE_MONTAGE}"

Voici un exemple complet :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
# Nom d'hôte du serveur *Backup Storage* (cf. e-mail)
NOM_SERVEUR_BACKUPSTORAGE='ftpback-rbx1-2345.ovh.net'

# Nom du serveur OVH
NOM_DU_SERVEUR_OVH='ns0000000.ip-123-123-123.net'

# Dossier de votre serveur où vous voulez monter l'espace disque distant
POINT_DE_MONTAGE='/mnt/ovh_backup_storage'

# On s'assure que le point de montage existe
mkdir --parents "${POINT_DE_MONTAGE}"

# On monte le dossier
mount \
    -t nfs \
    ${NOM_SERVEUR_BACKUPSTORAGE}:/export/ftpbackup/${NOM_DU_SERVEUR_OVH} \
    "${POINT_DE_MONTAGE}"

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) :

1
2
3
4
5
cat >> /etc/fstab <<EOT

# Montage espace Backup Storage OVH
${NOM_SERVEUR_BACKUPSTORAGE}:/export/ftpbackup/${NOM_DU_SERVEUR_OVH} ${POINT_DE_MONTAGE} nfs defaults 0 0
EOT

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écuter borgmatic 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.

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
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
location:
    # […]
    repositories:
        # […]
        - /mnt/ovh_backup_storage/backups/{fqdn}

storage:
    encryption_passcommand: cat /etc/borgmatic/passphrase.txt
    # […]

hooks:
    before_actions:
        # Mounting (with workaround for https://projects.torsion.org/borgmatic-collective/borgmatic/issues/657)
        - test -d "/mnt/ovh_backup_storage" || mkdir --parents "/mnt/ovh_backup_storage"
        - mountpoint "/mnt/ovh_backup_storage" > /dev/null || mount -t nfs "ftpback-rbx1-2345.ovh.net:/export/ftpbackup/ns0000000.ip-123-123-123.net" "/mnt/ovh_backup_storage"

    after_actions:
        # Unmounting (with workaround for https://projects.torsion.org/borgmatic-collective/borgmatic/issues/657)
        - "nohup /bin/sh -c 'sleep 5s ; findmnt --type fuse --source borgfs || { mountpoint \"/mnt/ovh_backup_storage\" && umount \"/mnt/ovh_backup_storage\" ; }' > /dev/null 2>&1 &"
    # […]

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.