J’utilisais jusqu’ici Backintime, mais ai eu des problèmes avec. Surtout, Backintime nécessitait un accès SSH côté serveur, ce qui était un gros risque de sécurité.

Pourquoi j’ai changé de logiciel

A l’époque où j’avais choisi Backintime, j’avais déjà hésité avec DejaDup. Il était (et est toujours) préinstallé avec Ubuntu (pratique), et en est le système de sauvegardes mis en avant. Mais, à l’époque, DejaDup ne marchait pas très bien (j’avais notamment eu des sauvegardes qui plantaient, et surtout des sauvegardes non restaurables). Il avait peu de fonctionnalités, et n’était pas bien supporté (peu de contributeurs pour corriger les bugs).

Ca m’avait conduit à choisir Backintime, tout en constatant que son repo git n’avait pas beaucoup d’activité. J’avais créé une image docker pour cet usage (que je devais maintenir), et dans laquelle j’avais dû mettre quelques bricolages pour limiter le risque de sécurité en cas de compromission.

Depuis, DejaDup est bien mieux supporté, et n’a plus les bugs que j’avais constatés. Il nécessite « seulement » un accès sftp (ou webdav), ce qui limite les risques de sécurité. Et il fait aussi de la compression des données, et du chiffrement avec un algorithme fiable (contrairement à celui de Backintime).

De son côté, Backintime n’a quasiment pas évolué (même si une nouvelle équipe vient de reprendre la maintenance), et j’ai eu des bugs à chaque montée de version d’Ubuntu, obligeant à lancer des lignes de commande pour contourner (perte des mots de passes sauvegardés, incompatibilités etc)… D’autre part, impossible de demander à Backintime de vraiment interrompre une sauvegarde (par exemple si on a un accès Internet payant/limité): on peut l’interrompre, mais il se relance dans le quart d’heure qui suit quand on utilise anacron… Ajouté le 28/08/2023: Et certains problèmes gênants persistent, comme https://github.com/bit-team/backintime/issues/445.

Bref, si c’est la partie sécurité qui m’a poussé à remplacer Backintime, c’est aussi pour éliminer des problèmes peu adaptés aux utilisateurs finaux chez qui je l’avais déployé.

Pour autant, DejaDup garde quelques inconvénients par rapport à Backintime:

• pas de multi-profil: on ne peut sauvegarder que vers une seule destination, une seule liste de répertoires. Ca suffit pour la plupart des usages. Mais, sur certaines machines, j’ai gardé du backintime en plus de DejaDup, pour avoir plusieurs destinations
• Paramétrage moins fin de la durée de rétention. Mais il consomme moins d’espace disque grâce à la compression, et beaucoup moins d’inodes car il concatène dans des fichiers de 25 Mo (ce qui est bien plus pratique pour mesurer la consommation disque de chaque utilisateur avec la ligne de commande « du » par exemple)
• Il consomme bien plus de CPU sur l’appareil à sauvegarder, pendant la sauvegarde
• Afficher et parcourir le contenu des sauvegardes est plus lent au premier accès

Implémentation côté serveur

En phase transitoire, j’ai pu utiliser les mêmes conteneurs SSH que j’utilisais pour Backintime (car « qui peut le plus peut le moins »). Mais ensuite je suis passé sur des conteneurs SFTP, qui offrent une surface d’attaque bien moins importante.

Sur mon cluster kube, j’ai utilisé le chart Helm https://artifacthub.io/packages/helm/sj14/sftp-server (auquel j’ai très modestement contribué pour coller à mes besoins), avec l’image docker https://hub.docker.com/r/huettner94/sftp (pour compatibilité avec mes machines ARM)

Je déploie un pod par utilisateur (pour mieux cloisonner en termes de sécurité, même si j’aurais pu tout mettre dans un seul pod), avec des données montées sur un gros disque dur local, sur un PV utilisant le provisioner local-path de k3s (en faisant simplement un lien symbolique de /var/lib/rancher/k3s/storage vers un répertoire du disque dur).

Voici un exemple de values.yaml:

image:
  repository: huettner94/sftp
  tag: "alpine"

sftp:
  hostKeys:
    # -- private ED25519 host key
    ed25519: |
      -----BEGIN OPENSSH PRIVATE KEY-----
      (...)
      -----END OPENSSH PRIVATE KEY-----
    # -- private RSA host key
    rsa: |
      -----BEGIN OPENSSH PRIVATE KEY-----
      (...)
      -----END OPENSSH PRIVATE KEY-----
  users:
    - name: dejadup
      password: # no password: using ssh key
      uid: "1000"
      gid: "1000"
      dirs:
        - firstcomputer
        - secondcomputer
      pubKeys:
        - ssh-rsa (...)
        - ssh-rsa (...)

persistentVolume:
  enabled: true
  size: 200Gi
  storageClass: local-path-retain # this is the storageClass local-path of k3s, configured with "Retain" reclaimPolicy, so that data is kept if I remove the PVC
  subPath: "."

service:
  type: NodePort # To be able to reach the pod from the Internet
  nodePort: 30344 # To always have the same port

nodeSelector:
  kubernetes.io/hostname: serverWhereMyHardDriveIsConnected

probes:
  startup: true
  liveness: false # because my very small server (Olinuxino A20) gets overwhelmed when DejaDup is sending its data, and I don't want the pod to be restarted in that case
  readiness: false # same

J’utilise un uid/gid non-root pour le user SFTP. Mais l’image docker elle-même ne peut hélas tourner que sous root.

J’ai aussi fixé la clé privée SSH, sinon elle est re-générée à chaque redémarrage du pod.