.. -*- 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