Backrest

Soyons honnêtes deux secondes : la "stratégie de sauvegarde" de la plupart des homelabbers, c'est avoir copié quelques dossiers sur une clé USB une fois en 2019, et espérer que tout ira bien. Backrest est là pour arranger ça, sans vous forcer à apprendre un outil en ligne de commande qui fait peur.

Sous le capot, Backrest est une interface web propre posée sur restic, un moteur de sauvegarde open-source qui a fait ses preuves. Restic fait le vrai travail (chiffrer, dédupliquer, et envoyer vos données là où vous le lui dites) ; Backrest vous donne des boutons et des formulaires plutôt qu'un mur d'options à retenir.

La règle du 3-2-1, ou pourquoi une seule sauvegarde n'en est pas une

Avant d'installer quoi que ce soit, parlons de la règle qui compte vraiment ici, parce qu'une sauvegarde mal pensée vous donne une fausse confiance, ce qui est pire que pas de sauvegarde du tout.

La règle du 3-2-1 dit :

• 3 copies de vos données : l'originale, plus au moins deux sauvegardes.
• 2 types de stockage différents : pas deux copies sur le même disque, ni sur deux disques dans la même machine.
• 1 copie hors site : physiquement ailleurs, pas dans la même pièce, la même maison ou le même bâtiment que l'original.

Chaque chiffre ferme un scénario de panne précis :

• Une seule (1) sauvegarde ? Une seule erreur (un rm -rf malheureux, une restauration ratée, un fichier corrompu copié par-dessus le bon sans que vous le voyiez) peut emporter votre seul filet de sécurité en même temps que l'original.
• Des sauvegardes sur le même type de stockage (disons, un second disque interne dans le même serveur) ? Une surtension, un bug de firmware, ou une alimentation bas de gamme qui lâche peuvent très bien emporter tous les disques du boîtier d'un coup.
• Pas de copie hors site ? Un incendie, une inondation, un vol, ou "j'ai débranché la mauvaise multiprise" se moquent du nombre de disques que vous avez, s'ils sont tous dans la même pièce.

C'est aussi exactement pour ça que le RAID n'est pas une sauvegarde : le RAID garde un service en marche quand un disque meurt, il ne fait rien contre un ransomware qui chiffre tous les fichiers qu'il peut atteindre, une suppression malheureuse, ou votre maison qui prend feu. Backrest, pointé vers une destination en dehors de votre serveur, est ce qui couvre réellement ces cas-là.

Ce que Backrest sauvegarde, et où

Deux concepts à connaître avant de cliquer partout :

• Un dépôt (repository) est la destination : un espace de stockage chiffré et dédupliqué. C'est votre "2" et votre "1" de la règle ci-dessus, un disque externe, un autre serveur, ou du stockage cloud.
• Un plan est la règle que vous définissez : quels dossiers sauvegarder, vers quel dépôt, selon quel planning, et combien d'anciens instantanés (snapshots) conserver.

Vous pouvez avoir plusieurs plans sauvegardant vers plusieurs dépôts en même temps, ce qui est exactement comment on construit un vrai 3-2-1 : un plan vers un dépôt local pour des restaurations rapides, un autre plan vers un dépôt hors site pour le scénario "ma maison brûle".

Installation

---
services:
  backrest:
    image: garethgeorge/backrest:latest
    container_name: backrest
    restart: unless-stopped
    ports:
      - 9898:9898
    volumes:
      - ./data:/data
      - ./config:/config
      - ./cache:/cache
      # Tout ce que vous voulez que Backrest puisse sauvegarder doit
      # aussi être monté ici : la stack ne voit que ce qu'on lui donne.
      - /srv/docker:/userdata/docker:ro
      - /etc:/userdata/etc:ro
      - /home:/userdata/home:ro
    environment:
      - BACKREST_DATA=/data
      - BACKREST_CONFIG=/config/config.json
      - XDG_CACHE_HOME=/cache
      - TZ=Europe/Paris

services:
  backrest:
    #...
    labels:
      - com.centurylinklabs.watchtower.enable=true

Créer votre premier dépôt

Dans Backrest, allez dans Add Repo. Le formulaire est découpé en plusieurs sections, voici ce que fait chaque champ :

• Repo Name : ce qui vous aidera à le reconnaître plus tard, cle-usb ou vps-hors-site par exemple. Impossible de le renommer ensuite, choisissez quelque chose que vous ne regretterez pas.
• Auto Unlock : laissez désactivé sauf si vous comprenez bien ce que ça fait. Restic verrouille un dépôt pendant qu'il y travaille, pour qu'un second processus ne corrompe pas tout en écrivant en même temps. Auto Unlock retire ce verrou automatiquement au démarrage, pratique si Backrest a planté en pleine sauvegarde et laissé un verrou fantôme, mais réellement dangereux si deux machines écrivent un jour dans le même dépôt en même temps. Pour la configuration mono-serveur de cet article, c'est un confort mineur ; laissez désactivé en cas de doute.
• Shared : ne concerne que la fonctionnalité multihost de Backrest (plusieurs de vos machines gérant la même configuration de dépôt). Ignorez-le pour un serveur unique.
• Repository URI : là où les données vivent réellement. C'est ce champ qui change pour chaque destination ci-dessous.
• Password : le mot de passe de chiffrement de ce dépôt, cliquez sur Generate pour en générer un solide aléatoirement. Conservez-le quelque part en dehors de ce serveur, un gestionnaire de mots de passe, une note sur votre téléphone, n'importe où sauf un fichier texte posé à côté des sauvegardes qu'il protège. Perdez-le, et chaque sauvegarde devient un tas de bruit illisible et coûteux, sans exception, même pour les développeurs de restic.
• Env Vars : là où vous collerez les identifiants pour les destinations qui en ont besoin (S3 et B2 plus bas). Un disque local et le SFTP n'en ont besoin d'aucun.

Sauvegarder vers un disque local ou une clé USB

La copie hors site la plus simple qui soit est un disque que vous déplacez physiquement ailleurs après chaque sauvegarde, ou le disque d'une seconde machine joint par le réseau. Dans les deux cas, du point de vue de Backrest c'est juste un dossier, donc la configuration est identique : branchez le disque (ou montez le partage réseau) sur l'hôte, ajoutez-le aux volumes du fichier compose comme vous l'avez fait pour /srv/docker plus haut, puis dans le champ Repository URI, utilisez le chemin tel qu'il apparaît à l'intérieur du conteneur :

/userdata/disque-sauvegarde

Voilà, aucun identifiant, aucune variable d'environnement. C'est aussi le dépôt le plus rapide pour restaurer, puisqu'il n'y a aucun aller-retour réseau, ce qui en fait un excellent choix pour votre copie de "récupération rapide", accompagnée d'une vraie copie hors site ci-dessous pour le scénario "ma maison brûle".

Sauvegarder vers un autre serveur

Pas de compte cloud, pas de problème : si vous avez un accès SSH à une autre machine, le serveur d'un ami, un petit VPS pas cher, un Raspberry Pi chez de la famille, c'est un dépôt hors site parfaitement valable, et ça ne coûte que ce que cette machine vous coûte déjà.

D'abord, assurez-vous que ce serveur peut se connecter en SSH à l'autre sans taper de mot de passe à chaque fois :

ssh-keygen -t ed25519 -f /srv/docker/backrest/config/id_ed25519 -N ""
ssh-copy-id -i /srv/docker/backrest/config/id_ed25519.pub votreutilisateur@lautreserveur

Montez cette clé dans le conteneur en l'ajoutant aux volumes du fichier compose :

    volumes:
      # ...
      - ./config/id_ed25519:/root/.ssh/id_ed25519:ro

Redéployez la stack, puis dans Backrest utilisez :

sftp:votreutilisateur@lautreserveur:/chemin/vers/les/sauvegardes

Avancé : stockage objet dans le cloud

Un disque local ou le serveur de secours d'un ami couvre très bien la règle du 3-2-1, et ne coûte rien de plus que ce que vous possédez déjà. Le stockage objet dans le cloud est l'autre option classique, intéressante quand vous voulez une copie hors site qui ne dépend pas du matériel de quelqu'un d'autre restant allumé, pour un coût de quelques centimes à quelques euros par mois selon ce que vous sauvegardez.

Backblaze B2

Backblaze B2 est du stockage objet pensé exactement pour cet usage, et c'est généralement l'option la moins chère pour le schéma "on écrit souvent, on lit rarement" d'une sauvegarde.

Créez un bucket dans votre compte Backblaze, puis générez une clé d'application limitée à celui-ci. Dans Backrest, utilisez :

b2:nom-de-votre-bucket:backrest

Avec les variables d'environnement suivantes :

Stockage compatible S3

S3 n'est pas juste un truc Amazon, c'est un protocole de stockage que la plupart des fournisseurs cloud parlent (OVH, Scaleway, MinIO si vous auto-hébergez le vôtre, et bien d'autres), ce qui en fait un choix solide et portable si vous préférez ne pas dépendre d'un fournisseur en particulier.

Créez un bucket chez le fournisseur de votre choix, puis dans le champ Repository URI de Backrest, utilisez :

s3:https://s3.votre-fournisseur.com/nom-de-votre-bucket/backrest

Pour du vrai AWS S3, retirez le endpoint personnalisé :

s3:s3.amazonaws.com/nom-de-votre-bucket/backrest

Avec les variables d'environnement suivantes :

Maintenance du dépôt (optionnel, mais à mettre en place une fois pour toutes)

Retour dans l'onglet Scheduling, trois politiques gardent un dépôt en bonne santé dans le temps. Aucune n'est nécessaire pour commencer à sauvegarder, restic fonctionne très bien sans jamais y toucher, mais elles valent la peine d'être comprises une fois que votre dépôt tourne depuis un moment :

Créer un plan de sauvegarde

Retour dans Backrest, allez dans Add Plan. Ce formulaire couvre quoi sauvegarder et quand, contrairement au formulaire de dépôt ci-dessus, qui ne couvre que où :

• Plan Name : même règle que le nom du dépôt, choisissez quelque chose de clair, impossible à changer ensuite.
• Repository : celui que vous venez de créer plus haut.
• Paths : cliquez sur Add pour ajouter une ligne, puis tapez le chemin côté conteneur de ce que vous avez monté plus haut, c'est un champ texte, mais il autocomplète les vrais chemins du système de fichiers du conteneur au fur et à mesure, pratique pour confirmer qu'un montage a bien atterri là où vous pensez. /userdata/docker pour vos stacks, /userdata/etc pour votre config système, /userdata/home pour vos propres fichiers. Cliquez à nouveau sur Add pour chaque dossier supplémentaire, le petit bouton - retire une ligne dont vous n'avez plus besoin.
• Excludes et Excludes (Case Insensitive) : des motifs à ignorer au sein de ces chemins, pratique pour les dossiers de cache ou tout ce qui est vraiment jetable et qui gonflerait chaque instantané pour rien.
• Schedule Type : les trois mêmes choix que les plannings du dépôt ci-dessus, Disabled, un Interval, ou une Cron Expression. Un cron nocturne du type 0 3 * * * (tous les jours à 3h du matin) est un défaut raisonnable pour un homelab.
• Retention Policy : combien d'instantanés conserver, et pendant combien de temps. By Time Period vous permet de dire "garder 7 quotidiens, 4 hebdomadaires, 6 mensuels" indépendamment, ce qui vous donne largement assez de points de restauration étalés dans le temps sans que le dépôt grossisse indéfiniment, puisque restic déduplique de toute façon les données inchangées entre les instantanés. By Count conserve à la place simplement les N derniers instantanés, quel que soit leur âge. Latest (Count) en plus de l'un ou l'autre mode garantit qu'un nombre minimum d'instantanés récents survit toujours, quoi que dise le reste de la politique.
• Advanced : Backup Flags vous permet de passer des options supplémentaires directement à la commande restic backup sous-jacente pour tout ce que ce formulaire n'expose pas ; Hooks exécute des scripts ou envoie des notifications sur les événements de sauvegarde, le même mécanisme que l'onglet Hooks du dépôt, mais limité à ce seul plan au lieu de tous les plans utilisant le dépôt.

Cette politique de rétention est d'ailleurs votre vraie défense contre les ransomwares : si quelque chose commence à chiffrer vos fichiers à 2h du matin, la sauvegarde de ce soir est compromise, mais celle de la semaine dernière ne l'est pas, et restic vous permet de restaurer depuis n'importe laquelle d'entre elles.

Restaurer une sauvegarde

Une sauvegarde qu'on n'a jamais essayé de restaurer est un pari, pas un plan, ça vaut le coup de le faire une fois avant d'en avoir vraiment besoin. Ouvrez le plan, cliquez sur un instantané, dépliez Snapshot Browser jusqu'à ce dont vous avez besoin, puis cliquez sur le menu ... à côté et choisissez Restore to path.

Laissez le champ de chemin vide et Backrest l'envoie directement vers les téléchargements de votre navigateur, l'option la plus simple pour récupérer un seul fichier. Tapez un chemin et Backrest écrit plutôt les données restaurées dans le conteneur à cet endroit, et il pré-remplit un dossier temporaire du type /userdata-backrest-restore-<id du snapshot>, volontairement pas votre montage d'origine.

Ce choix par défaut n'est pas un hasard : /srv/docker, /etc et /home sont montés en :ro, donc restic ne peut pas y réécrire, restaurer directement dans /userdata/docker échoue avec une erreur de système de fichiers en lecture seule. Restaurez vers ce dossier temporaire suggéré (ou téléchargez à la place), vérifiez ce que vous avez récupéré, puis recopiez les fichiers à leur vraie place vous-même avec sudo cp -a, depuis l'hôte, en dehors de Backrest. Une étape de plus, mais ça garantit aussi qu'une restauration ne peut jamais écraser silencieusement des données en cours d'utilisation, exactement la prudence qu'on veut en plein incident.

Et voilà, vous avez maintenant une vraie stratégie de sauvegarde plutôt qu'un dossier appelé sauvegarde_finale_v2_LAVRAIE.