path: root/content/Informatique/2022-09-cold.rst

.. -*- mode: rst -*-
.. -*-  coding: utf-8 -*-

============================================
Les sauvegardes dans le cloud avec duplicity
============================================

:date: 3020-09-02
:tags: sauvegarde, gpg
:status: draft

Le problème avec les sauvegardes est de savoir où les mettre. La plupart du
temps nous n’en avons pas besoin (et le plus longtemps possible souhaitons-le…)
et les supports sur lesquels nous les entreposons vieillissent. À noter qu’il
est également recommandé de doubler les sauvegardes (principe 3-2-1), ce qui
s’avère fastidieux si l’on fait cela nous-même à la maison.

Une solution est de mettre les sauvegarde dans le cloud, mais cela implique
alors un problème de sécurité : tout ce qui est en ligne est publique. Bien que
les applications de sauvegarde permettent de chiffrer les données avant de les
mettre en ligne, toutes ne proposent pas les mêmes fonctionnalités. Par
exemple, Borg_ utilise la `même clef`_ pour chiffrer et déchiffrer les
sauvegardes, ce qui n’est pas sur (cela oblige a partager le mot de passe
partout).

.. _Borg: https://www.borgbackup.org/
.. _même clef: https://github.com/borgbackup/borg/issues/672

De plus, cela met dans la balance la question du cout des sauvegardes, toutes
les solutions ne se valent pas, et le volume n’est pas négligeable… Pour
réduire les couts, il est possible d’utiliser le principe des sauvegardes à
froid : les sauvegardes sont en quelque sorte *givrées* et ne sont pas
disponibles de suite en cas de besoin (quelques heures sont nécessaires pour
les récupérer).  L'inconvénient étant une non-disponibilité immédiate des
fichiers archivés. Cela en soit ne pose pas de problème pour sauvegarder ses
photos, mais cela empêche de mettre en place une sauvegarde incrémentale,
puisqu'il est nécessaire pour l'outil de sauvegarde de pouvoir comparer la
liste des fichiers archivés afin de savoir lesquels mettre à jour.

Il faut donc trouver une solution qui, en plus de chiffrer les données avant de
les envoyer en ligne, conserve un moyen de mettre à jour les sauvegardes sans
avoir besoin de les dégeler avant.

.. contents::
  :depth: 1

Présentation de la solution
===========================

Dans cet article, je vais proposer une solution qui utilise le stockage à froid
pour y mettre les archives et le stockage à chaud pour toutes les données
d'index. De cette manière l'application est capable de récupérer les
métadonnées afin d'identifier les données à mettre à jour en temps réel, et la
récupération des sauvegardes, elle, se fera uniquement sur les données ayant
été dégelées.

Cette solution se base sur le logiciel `duplicity`_. C’est une application en
python, qui se base sur gpg pour chiffrer les fichiers avant de les envoyer
vers le support de destination.

.. _duplicity: https://duplicity.gitlab.io/

Commandes de base
=================

Avant d’envoyer nos fichiers dans le cloud, nous allons nous assurer que le
principe des sauvegardes fonctionne sur notre ordinateur.

.. contents::
   :local:

On va se faire une fonction générale qui appellera duplicity toujours de la
même manière avec les mêmes arguments communs. Ce petit script modifie
également l’ordre des paramètres donnés à duplicity pour plus de simplicité par
la suite : quel que soit la commande lancée, nous aurons toujours l’ordre
suivant :

1. la référence vers la sauvegarde
2. la commande à appliquer
3. les paramètres supplémentaires

.. code-block:: bash

  #!/bin/sh

  enc_key=…
  sign_key=…

  # The backup function with all the common settings
  # Arguments
  #       - The duplicity target (see later)
  #       - Other arguments to give to duplicity
  backup() {
          local BACKUP=$1
          shift
          duplicity \
             --encrypt-key ${enc_key} \
             --sign-key ${sign_key} \
             --file-prefix-manifest 'hot_' \
             --file-prefix-signature 'hot_' \
             --file-prefix-archive 'cold_' \
             $* \
             ${BACKUP}
  }

  restore() {
          local BACKUP=$1
          # We remove the two first parameters : the backup path, and the
          # restore command
          shift 2
          duplicity \
             --encrypt-key ${enc_key} \
             --file-prefix-manifest 'hot_' \
             --file-prefix-signature 'hot_' \
             --file-prefix-archive 'cold_' \
             restore \
             ${BACKUP} \
             $*
  }

  case $2 in
          restore)
                  restore $*
                  ;;
          *)
                  backup $*
                  ;;
  esac



enc_key
  Il s’agit de la clef publique utilisée pour chiffrer les données. Ce
  paramètre est obligatoire dans toutes nos commandes pour que duplicity
  utilise gpg (si le paramètre est absent, les sauvegardes sont chiffrées à
  l’aide d’une clef symétrique — un simple mot de passe).

  Seul le possesseur de la clef privée pourra les déchiffrer. C’est intéressant
  car cela permet de chiffrer les données pour un (ou plusieurs) utilisateur
  sans que celui-ci ne nous communique sa clef privée.

sign_key
  Ce paramètre est optionnel et permet de spécifier une clef de signature de
  l’archive. Cela permet de s’assurer que la sauvegarde a bien été émise par
  l’utilisateur attendu.

  \

Les clefs de chiffrement ou signature ne sont pas forcément celles de
l’utilisateur lançant la sauvegarde, mais doivent être connues de celui-ci.
Il est possible de donner plusieurs clefs si l’on souhaite créer des
sauvegardes qui puissent être déchiffrées par plusieurs personnes.

sauvegarde
  Il s’agit de la destination de la sauvegarde, ce paramètre est à mentionner
  systématiquement (que nous fassions une sauvegarde, une restauration ou une
  consultation).

  Pour l’instant nous allons renseigner une destination locale afin de faire
  nos tests avant d’envoyer nos données dans le cloud, par exemple
  :literal:`file:///tmp/backup`

En plus de ces paramètres qui sont présents à chaque fois, nous allons avoir
des paramètres supplémentaires qui vont varier en fonction des commandes que
nous souhaitons exécuter.

Sauvegarder les données
-----------------------

On peut lancer une synchronisation complète avec l’instruction :literal:`full` :

.. code-block:: console

  $ backup.sh "${sauvegarde}" \
    full "${chemin à sauvegarder}"

Les mises à jour (delta) uniquement sont lancées en remplaçant :literal:`full` par
:literal:`incremental` :

.. code-block:: console

 $ backup.sh "${sauvegarde}" \
   incremental "${chemin a sauvegarder}"


Le paramètre :literal:`--full-if-older-than` permet de combiner les deux
actions, en lançant une nouvelle sauvegarde complète seulement si la précédente
a été réalisée depuis plus d’une certaine durée (ici une semaine) :

.. code-block:: console

  $ backup.sh "${sauvegarde}" \
    incremental --full-if-older-than 1W \
    "${chemin a sauvegarder}"


Lister les sauvegardes
----------------------

Une fois la sauvegarde faite, nous avons la possibilité de consulter les
sauvegardes réalisées en accédant juste aux métadonnées avec la commande
:literal:`collection-status` :

.. code-block:: console

 $ backup.sh "${sauvegarde}" \
   collection-status
 MultiBackend: pca://duplicity: 7 files
 MultiBackend: swift://duplicity_hot: 14 files
 Last full backup date: Wed Sep  2 09:36:13 2020
 Collection Status
 -----------------
 Connecting with backend: BackendWrapper
 Archive dir: …

 Found 2 secondary backup chains.
 …

 Found primary backup chain with matching signature chain:
 -------------------------
 Chain start time: Wed Sep  2 09:36:13 2020
 Chain end time: Wed Sep  2 12:01:17 2020
 Number of contained backup sets: 5
 Total number of contained volumes: 0
  Type of backup set:                            Time:      Num volumes:
          Incremental         Wed Sep  2 09:38:09 2020                 0
          Incremental         Wed Sep  2 11:32:19 2020                 0
          Incremental         Wed Sep  2 12:00:56 2020                 0
          Incremental         Wed Sep  2 12:01:17 2020                 0
 -------------------------
 No orphaned or incomplete backup sets found.

Nettoyer les sauvegardes
------------------------

duplicity inclue dans ses commandes de bases les outils pour supprimer
automatiquement les sauvegarde trop anciennes. Par exemple la commande suivante
ne conserve que quatre jeux de sauvegarde complets :

.. code:: console

  $ backup.sh "${sauvegarde}" \
    --force remove-all-but-n-full 4
  Local and Remote metadata are synchronized, no sync needed.
  Last full backup date: Mon Apr 25 21:28:17 2022
  No old backup sets found, nothing deleted.

Ici le paramètre :literal:`--force` est utilisé pour supprimer les fichiers,
sans cela, l’application ne fait que lister les fichiers sans réellement agir.

Afficher les fichiers sauvegardés
---------------------------------

.. code-block:: console

 $ backup.sh "${sauvegarde}" \
   list-current-files
 MultiBackend: pca://duplicity: 7 files
 MultiBackend: swift://duplicity_hot: 14 files
 Synchronizing remote metadata to local cache...
 GnuPG passphrase for decryption:
 MultiBackend: pca://duplicity: 7 files
 MultiBackend: swift://duplicity_hot: 14 files
 Last full backup date: Wed Sep  2 09:36:13 2020
 Wed Sep  2 09:28:55 2020 .
 Sat Jan 27 17:44:34 2018 fichier1
 Sat Jan 27 17:44:34 2018 fichier2

Il est possible d'ajouter une version spécifique en précisant l'heure de la
sauvegarde souhaitée :

.. code-block:: console

 $ backup ${sauvegarde} \
    list-current-files --time 20200902T072859Z


Restauration
------------

Sans paramètre donné, ou avec le paramètre :literal:`restore`, c’est la
restauration de la dernière sauvegarde qui est exécutée :

.. code-block:: console

 $ backup.sh ${sauvegarde} \
    restore $(path/to/restore)

.. admonition:: Mot de passe GPG
  :class: note

  Lors de la restauration, duplicity demande le mot de passe GPG. Nous pouvons
  valider dans rien saisir à ce moment là car nous utilisons la clef GPG pour
  déchiffrer le contenu des archives.

Là encore, si nous ajouter la date de la sauvegarde, nous allons récupérer
une version donnée :

.. code-block:: console

 $ backup.sh ${sauvegarde} \
    restore --time 20200902T072859Z \
    $(path/to/restore)

Faire des sauvegarde sans distribuer ses clefs
==============================================

Nous l’avons vu, en donnant une clef publique, il est possible de faire une
sauvegarde pour un utilisateur précis. Cela permet de faire des sauvegardes
automatiques dans une tache planifiée au niveau du système. C’est utile si l’on
dispose d’un NAS par exemple : les sauvegardes sont faites automatiquement par
le système et la restauration pourra être faite par les utilisateurs concernés.

Pour cela, il est nécessaire d’exporter sa clef publique et l’importer sur le
système cible :


.. code:: bash

  # Exporter sa propre clef
  gpg --export -a ${mykey} > public.key

  # À importer avec l’utilisateur voulant faire la sauvegarde
  gpg --import public.key

Toutefois, il ne faut pas s’arreter là : si nous lançons la sauvegarde de
suite, nous allons avoir une erreur de ce type :

.. code:: bash

  duplicity --encrypt-key ${mykey} /tmp/source/ file:///tmp/backup
  Local and Remote metadata are synchronized, no sync needed.
  Last full backup date: none
  No signatures found, switching to full backup.
  GPGError: GPG Failed, see log below:
  ===== Begin GnuPG log =====
  gpg: 2421BCBD56473645: There is no assurance this key belongs to the named user
  gpg: [stdin]: encryption failed: Unusable public key
  ===== End GnuPG log =====

En effet, la clef a été importée, mais n’a pas été considérée comme sure, une
petite manipulation est nécessaire pour ce faire :

.. code:: console

  $ gpg --edit-key ${mykey}
  gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc.
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.

  [détail des clefs]

  gpg> trust
  [détail des clefs]

  Décidez maintenant de la confiance que vous portez en cet utilisateur pour
  vérifier les clefs des autres utilisateurs (en regardant les passeports, en
  vérifiant les empreintes depuis diverses sources, etc.)

    1 = je ne sais pas ou n'ai pas d'avis
    2 = je ne fais PAS confiance
    3 = je fais très légèrement confiance
    4 = je fais entièrement confiance
    5 = j'attribue une confiance ultime
    m = retour au menu principal

  Quelle est votre décision ? 5
  Voulez-vous vraiment attribuer une confiance ultime à cette clef ? (o/N) o

  [détail des clefs]
  Veuillez remarquer que la validité affichée pour la clef n'est pas
  forcément correcte avant d'avoir relancé le programme.

  gpg>

Cette opération n’est pas liée à duplicity, mais à GPG et la manière dont
celui-ci gère la chaine de confiance entre les différentes clefs.


Utiliser un fichier de configuration
====================================

Jusqu’à présent, nous avons utilisé comme chemin de sauvegarde le répertoire où
nous souhaitons enregistrer les fichiers sur le disque. Pour avoir plus de
souplesse dans nos options, nous allons créer un fichier de configuration. Ce
fichier, au format *json* permet de combiner plusieurs destinations de
sauvegarde (par exemple pour faire une copie dans deux répertoires
simultanément), ou de construire des chemin de destination avancés.

    "multi://$(realpath config.json)?mode=mirror&onfail=abort"

mode
  Ce paramètre permet d’indiquer que toutes les sources de destination dans le
  fichier doivent être employées en miroir (les données seront dupliquées sur
  chacune d’elles). Par défaut, duplicity va alterner entre ces différentes
  sources pour copier les données

  \


onfail
  Ce paramètre indique que toute erreur durant la sauvegarde est bloquante. Par
  défaut, l’application va tenter de continuer la sauvegarde sur le prochain
  support disponible et ne lèvera l’erreur qu’après avoir tenté tous les
  supports disponibles.

  \


Le fichier de configuration est au format json est peut être utilisé dans sa
forme la plus simple :

.. code:: json

  [
   {
    "description": "a comment about the backend"
    "url": "file:///path/to/dir",
   },
   {
    "description": "a miror"
    "url": "file:///path/to/dir2",
   }
  ]

Des paramètres supplémentaires peuvent être configuré, permettant notamment de
répartir les fichiers selon leur typologie et ce, sans perdre cette possibilité
de faire les sauvegardes en double :

- mettre les archives dans un répertoire dédié
- mettre les indexes dans un autre répertoire

Revenons un instant sur les trois lignes qui sont présentes dans le script créé
au début de cet article :

.. code:: bash

    …
    --file-prefix-manifest 'hot_' \
    --file-prefix-signature 'hot_' \
    --file-prefix-archive 'cold_' \
    …

Ces préfixes donnés aux types de fichiers générés par duplicity sont à mettre
en relation avec des filtres, qui permettent d’aiguiller les fichiers dans la
configuration. Tous les fichier :literal:`hot_` seront envoyés vers le
répertoire de destination des indexes, et tous les fichiers :literal:`cold_`
seront envoyés dans le répertoire des archives :

.. code:: json

  [
   {
    "description": "The indexes"
    "url": "file:///path/to/indexes",
    "prefixes": ["hot_"]
   },
   {
    "description": "The archives"
    "url": "file:///path/to/archives",
    "prefixes": ["cold_"]
   }
  ]

On peut mettre autant de destinations que nous le souhaitons, et les fichiers
seront donc automatiquement copiés vers toutes les destinations correspondantes
(si aucun préfixes n’est renseigné, il acceptera tous les fichiers).

Dans les nuages
===============

Maintenant que le système de sauvegarde fonctionne, nous allons ajouter un
niveau et transférer nos fichiers dans le cloud. Je me base ici sur
l’infrastructure d’OVH, puisque c’est là que j’héberge mes fichiers, mais tout
autre hébergeur peut également convenir.

Création des accès distants
---------------------------


Création
~~~~~~~~

Commencer par se créer un compte sur l'environnement d'OVH

.. image:: {static}/images/ovh_cold/user.webp
    :class: floatright
    :alt: Création d’un nouvel utilisateur

Lors de la création de l'utilisateur, s'assurer que le rôle `ObjectStore
Operator` est bien activé. Il n'est pas nécessaire que notre utilisateur ait
tous les rôles (nous voulons juste faire une sauvegarde).

Identifiant
~~~~~~~~~~~

.. image:: {static}/images/ovh_cold/config.webp
    :class: floatleft
    :alt: Récupération de l’identifiant

L’ensemble des informations du compte peuvent ensuite être récupérées dans un
fichier texte (sauf le mot de passe qui est à noter), ce fichier va nous servir
à générer la configuration de duplicity. Je renomme ce fichier
:literal:`user_duplicity.sh` et le conserve, il sera utilisé par la suite :

Configuration
-------------

Pour générer la configuration, il y un nombre important de paramètres à passer,
c’est pourquoi je vous propose le script :literal:`gen_config.sh` afin de
produire le fichier json avec les valeurs nécessaires (URL, mot de passe,
identifiant etc).

.. admonition:: Sécurité
  :class: danger

  Attention ! Le fichier json contient le mot de passe en clair, attention à ne
  pas conserver le fichier, ou restreindre les droits afin d’empêcher que
  celui-ci ne soit exposé.

.. figure:: {static}/images/mimetypes/application-x-executable.png
    :alt: get the file
    :align: center
    :target: {static}/resources/backup/gen_config.sh

    Télécharger

Il faut lui donner en paramètre le fichier téléchargé et la configuration à
lancer :

.. code-block:: console

 $ ./gen_config.sh ./user_duplicity.sh config.json backup_name
 Please enter your OpenStack Password: XXXXX
 $

(On retrouve ici le script :literal:`user_duplicity.sh` que l’on a téléchargé
depuis le site d’OVH et qui permet de retrouver toutes les informations sur le
serveur de stockage).

Notre fichier json va devenir la destination de nos sauvegardes. Puisqu’il
contient toutes les directives nécessaires, il suffit d’indiquer à duplicity de
l’utiliser comme emplacement de sauvegarde et l’application sera capable
d’orienter les fichiers vers le stockage à froid ou non automatiquement.

Lors de la première exécution, les répertoires nécessaires seront créés
automatiquement.

Dégeler les fichiers en masse
-----------------------------

Pour les opérations de contrôles et de restauration, je propose de commencer
par récupérer les fichiers gelés et les conserver en local. De cette manière
nous pourrons :

1. Contrôler l’intégrité de la sauvegarde
2. Procéder à une restauration de test de celle-ci.

L’interface d’OVH permet de dégeler un fichier, mais celle-ci n’est pas
pratique pour procéder à cette opération en masse. Pour ce faire, nous allons
nous connecter en SFTP directement, pour lancer l’opération de récupération.

.. image:: {static}/images/ovh_cold/degel.webp
    :class: floatright
    :alt: Attente du dégel des données

Il faut se connecter au serveur suivant :

.. code-block:: bash

  . user_duplicity.sh
  sftp pca@gateways.storage.${OS_REGION_NAME}.cloud.ovh.net

Le mot de passe de l’utilisateur est composé ainsi :

.. code-block:: bash

  ${OS_TENANT_NAME}.${OS_USERNAME}.${OS_PASSWORD}

.. admonition:: Compte d’accès
  :class: note

  L’utilisateur est toujours :literal:`pca`, c’est à travers le mot de passe
  qu’OVH identifie les ressources auxquelles nous sommes censer accéder.

Une fois connecté en sftp, il est possible de lancer le dégel de l'ensemble des
fichiers dans un répertoire donné sans passer par l'interface. Cela peut être
utile pour préparer une restauration (duplicity stocke ses fichiers en lots de
200Mo)

.. code-block:: console


  > cd backup_name
  > get *

La commande va échouer (impossible de récupérer les fichiers car ceux-ci sont
gelés), mais la demande sera transmise, et les fichiers vont passer en
préparation pour restauration.

Création d’une configuration locale
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

De la même manière que nous avions préparé un script pour générer un fichier de
configuration pour duplicity afin de sauver nos données, nous allons générer un
fichier qui va créer une configuration *locale* dans laquelle l’ensemble des
données seront chargées à partir du répertoire dans lequel nous aurons sauvé
nos fichiers.

Il faut comprendre que duplicity se soucie juste de retrouver les fichiers
qu’il souhaite restaurer selon la même arborescence qu’au moment de la
sauvegarde. Peut importe si la sauvegarde s’est faite dans le cloud et la
restauration à partir d’un disque local. Nous pouvons reconstruire nous même
cette arborescence, cela ne posera aucun problème à la restauration.

De cette manière, nous nous affranchissons des contraintes de temps (et du
réseau) pour toutes les opérations qui ont besoin de charger chaque archive.

.. figure:: {static}/images/mimetypes/application-x-executable.png
    :alt: get the file
    :align: center
    :target: {static}/resources/backup/gen_config_local.sh

    Télécharger