Différences

Ci-dessous, les différences entre deux révisions de la page.

--- tutoriel:sauvegardes_nomades_securisees [Le 08/03/2024, 09:42] – [Avertissements :] livier
+++ tutoriel:sauvegardes_nomades_securisees [Le 08/08/2026, 04:17] (Version actuelle) – [Rsnapshot] livier
@@ Ligne 1: / Ligne 1: @@
-{{tag>LTS_22.04 sauvegarde disque_USB chiffrement rsnapshot cryptsetup tutoriel BROUILLON}}
+{{tag>sauvegarde chiffrement tutoriel BROUILLON}}
 ====== Sauvegardes nomades sécurisées pour laptop ======
+<note warning>
+Il existe désormais des solutions intégrées complètes, plus puissantes, efficaces, et économes en ressources que la solution présentée ci-après.
+  * [[:deja-dup|Déjà Dup]] en particulier est installé par défaut sur Ubuntu, et extrêmement simple d'utilisation.
+  * [[:Restic]] propose aussi une solution tout-en-un qui convient aux cas les plus particulier,
+et ces solutions offrent en plus du chiffrement la compression et la déduplication, sont donc plus rapides et économes en ressources, et parce qu'elles vérifient automatiquement l'index et l'état des sauvegardes précédentes, elles sont aussi plus sûres (elles permettent aussi d'envisager très simplement plusieurs sauvegardes sur différents supports ou centres de stockages).\\
+Elles conviennent aussi parfaitement à un usage nomade et portable.
+</note>
 Pour qui utilise un Laptop comme ordinateur principal les sauvegardes sont toujours nécessaires, mais pas si évidentes. La solution “Cloud” est en fait le plus souvent un mirroir, et ce n’est donc une sauvegarde que en cas de perte de la machine principale, mais si un document est perdu sur la machine principale, il le sera aussi sur le mirroir.
@@ Ligne 11: / Ligne 19: @@
 ===== Contexte et buts =====
-Jusqu’à présent et depuis plus de 10 ans, j’utilisais un desktop avec un disque dur de travail et un autre pour les sauvegardes, automatisé par cron et [[https://doc.ubuntu-fr.org/rsnapshot|rsnapshot]]. Je n’avais à y penser que lorsque j’avais perdu quelquechose : je le retrouvais assez facilement, dans les répertoires correspondants aux dates d’il y a quelques jours, semaines ou mois, celon la situation. Bref, j’étais satisfait de ce système.
+Les besoins de sécurité augmentent : chiffrement de l’ordinateur pour les cas de perte ou de vol, et sauvegardes qui doivent nécessairement être hors de la machine ; idéalement en plusieurs lieux, genre bureau et domicile.
-Je prend maintenant un laptop comme ordi principal. Mes besoins de sécurité augmentent donc : chiffrage de l’ordinateur pour les cas de perte ou de vol, et sauvegardes qui doivent nécessairement être hors de la machine ; idéalement en plusieurs lieux, genre bureau et domicile.
-L’idée est donc de laisser un disque USB à ces endroits et, quand je vais les connecter, déclencher automatiquement un script qui fait automatiquement la sauvegarde adéquate. Ces disques que je vais laisser hors de mon contrôle direct doivent bien sur aussi être chiffrés, de façon à être ouverts automatiquement dans la procédure de sauvegarde, et aussi manuellement au cas ou je perdrais l’ordinateur.
+L’idée est de laisser un disque USB à ces endroits et, quand je vais les connecter, déclencher automatiquement un script qui fait automatiquement la sauvegarde adéquate. Ces disques que je vais laisser hors de mon contrôle direct doivent bien sur aussi être chiffrés, de façon à être ouverts automatiquement dans la procédure de sauvegarde, et aussi manuellement au cas ou je perdrais l’ordinateur.
-Le shéma sera une cascade de scripts : - [[https://doc.ubuntu-fr.org/rsnapshot|rsnapshot]] qui m’a toujours doné satisfaction - [[https://github.com/pigmonkey/cryptshot|Crypshot]] pour gérer le chiffrement de la partition accueillant les sauvegardes, qui appellera rsnapshot - [[https://github.com/pigmonkey/backitup|Backitup]] pour lancer les sauvegardes adéquates quand les disques externes sont connectés - La procédure ci dessous présente la configuration pour un “lieu” de sauvegarde, à “domicile”, il faut la refaire en l’adaptant légèrement pour mettre en place un deuxième “lieu” de sauvegarde, au “bureau”
+Le schéma sera une cascade de scripts : - [[https://doc.ubuntu-fr.org/rsnapshot|rsnapshot]] qui m’a toujours doné satisfaction - [[https://github.com/pigmonkey/cryptshot|Crypshot]] pour gérer le chiffrement de la partition accueillant les sauvegardes, qui appellera rsnapshot - [[https://github.com/pigmonkey/backitup|Backitup]] pour lancer les sauvegardes adéquates quand les disques externes sont connectés - La procédure ci dessous présente la configuration pour un “lieu” de sauvegarde, à “domicile”, il faut la refaire en l’adaptant légèrement pour mettre en place un deuxième “lieu” de sauvegarde, au “bureau”
 ===== Utiliser une partition chiffrée =====
@@ Ligne 30: / Ligne 36: @@
   * Apprenez à manipulez vos partitions chiffrées vous mêmes à la main. Vous voulez être compétents pour être en mesure de les utiliser quand vous aurez besoin de vos backups et que la situation vous échappera un peu…
   * Je réalise la plupart des opérations suivantes avec les outils graphiques de KDE. Je ne suis pas en mesure de donner les lignes de commande de façon suffisamment fiable pour une documentation publique. Suivez les étapes et faites attention à ce que vous faites.
-  * Toutes les commandes (ou presque) de ce tutoriel sont à passer en ''%%root%%'' (en utilisant ''%%sudo%%'') [Utiliser : ''%%sudo !!%%'' quand vous voulez passer ''%%en root%%'' la dernière commande que vous avez tenté en simple utilisateur].\\
+  * Toutes les commandes (ou presque) de ce tutoriel sont à passer en ''%%root%%'' (en utilisant ''%%sudo%%'')
+ <note tip>Utiliser : ''%%sudo !!%%'' quand vous voulez passer ''%%en root%%'' la dernière commande que vous avez tenté en simple utilisateur.</note>\\
   * Nous utilisons des scripts qui seront appelés en tant que root, mais que j’ai édité (plusieurs fois en mode essai-erreur) en tant qu’utilisateur. Il m’a fallu faire quelques ajustements au niveau des droits pour faire tout cela (commandes chown et chmod en sudo). [Par exemple, mettre “mon utilisateur” dans le groupe “root” et utiliser des [[:permissions|droits]] de type “root.root 760” pour que root puisse exécuter les scripts, moi pouvoir les éditer, et rien pour les autres] **Si vous n’êtes pas à l’aise avec ces manipulations, persévérez dans l’apprentissage de ces notions avant de configurer vos chiffrements ;-)**
-  * afin de voir les commandes qui passent quand on lance un script en console dans les phases de test : mettre ''%%set -x%%'' en début de script (et retirer ensuite)
 <note tip> afin de voir les commandes qui passent quand on lance un script en console dans les phases de test : mettre ''%%set -x%%'' en début de script (et retirer ensuite)</note>
@@ Ligne 99: / Ligne 105: @@
 === Montage et démontages des volumes chiffés ===
-Vérifiez que vous êtes vraiment capables de manipuler vos partitions chiffrées en dehors des scripts …
+<note important>Vérifiez que vous êtes vraiment capables de manipuler vos partitions chiffrées en dehors des scripts …</note>
   * Ouvrir la partition chiffrée, le mot de passe sera demandé :
@@ Ligne 110: / Ligne 116: @@
 <code bash>
 cryptsetup -v luksOpen --key-file <chemin/Keyfile> /dev/<target device> monVolume
+</code>
+  * Vérifier un mot de passe et son slot, sans ouvrir la partition :
+<code bash>
+cryptsetup -v luksOpen --test-passphrase /dev/<target device>
 </code>
   * Montage du mapper
@@ Ligne 134: / Ligne 146: @@
 Pour approfondissements, voir :
-Nous aurons besoin d’au moins deux clés pour ouvrir le conteneur :
+<note important>Nous aurons besoin d’au moins deux clés pour ouvrir le conteneur :</note>
   - Un “keyfile” (qui peut être n’importe quel fichier) dans l’ordinateur pour automatiser la sauvegarde. Cette clé qui ne sera pas utilisable à qui disposerait du disque seulement : le voleur ou vous après la perte de l’ordinateur.
@@ Ligne 159: / Ligne 171: @@
 </code>
 === Sauvegarder l’entête du conteneur ===
+<note important>
+Les entêtes des conteneurs luks contiennent les informations nécessaires au déchiffrage des données, notament les slots avec les mots de passe et les keyfiles. Ils peuvent être sauvegardés et restaurés, rétablissant à l'occasion les slots fonctionnels au moment de leur sauvegarde (même ceux fermés depuis!).
+Tester leur restauration n'est pas trivial, j'y renonce. La perte des entêtes de conteneurs est un risque comparable et complémentaire à la perte d'un disque dur ; dont il faut de toutes façon se protéger par la multiplication des sauvegardes. La valeur ajoutée de la sauvegarde des entêtes est donc faible pour la complication que cela demande. Faites comme vous voulez, voici les commandes de base si vous y tenez.
-Cet entête intégral est indispensable à l’ouverture du conteneur. On peut l’altérer volontairement pour rendre le conteneur illisible à qui que ce soit, il peut aussi y avoir un accident ! Attention, l’entête contient tous les slots de mots de passe et keyfiles. Le restaurer remettra donc ces slots à l’état du moment de la sauvegarde, réactivant d’anciens mots de passe éliminés. Cela peut être une bréche de sécurité si la sauvegarde de l’entête est (a été) accessible à un ancien collaborateur .
+<code>$ sudo cryptsetup luksHeaderBackup /dev/<target device> --header-backup-file <fichier_de_sauvegarde>
+$ sudo cryptsetup luksHeaderRestore /dev/<target device> --header-backup-file <fichier_de_sauvegarde>
-luksHeaderBackup /dev/<html><target device></html> –header-backup-file <html><file></html>
+</code>
-luksHeaderRestore /dev/<html><target device></html> –header-backup-file <html><file></html>
 ===== Utilisation des scripts =====
@@ Ligne 174: / Ligne 187: @@
 ==== Rsnapshot ====
-Voir la page dédiée [[https://doc.ubuntu-fr.org/rsnapshot|rsnapshot]]
+C'est le script de base des sauvegardes, le seul nécessaire pour des sauvegardes locales non chiffrées. sa grande qualité : utiliser des liens en dur pour accéder au même fichier physique (pas de perte de place) dans les différentes versions de sauvegarde, tant que le fichier n'a pas changé. Pour retrouver un fichier, on entre dans la sauvegarde adéquate (il y a quelques jours, semaines ou mois) et on navigue comme dans le répertoire d'origine.
+- sudo apt install rsnapshot
-Attentions particulières : - rsnapshot utilise les liens en dur pour donner accès au mêmes fichiers à partir des différents répertoires datés de chaque sauvegarde. C’est ce qui fait le charme de sa facilité de retrouver des fichiers. Ne fonctionne par sur les partition “fat” - Mettre **no_create_root 1** dans le fichier de configuration pour éviter que la sauvegarde ne remplisse le disque de l’ordinateur au cas ou un disque USB ne serait pas connecté au moment de la sauvegarde (en principe déjà prise en charge dans cryptshot). - Vous voudrez probablement tester votre configurration de rsnapshot avant de l’envoyer dans des volumes chiffrés. * Notez que lors de l’exécution des scripts suivants, nous utiliserons des fichiers de configuration spécifiques.
+- Configuration dans /etc/rsnapshot.conf
+-Tester votre configuration :
+$ rsnapshot configtest
+$ rsnapshot -t daily
+Nécessite partitions gérant les liens en dur (pas fat)
+Mettre **no_create_root 1** dans le fichier de configuration pour éviter que la sauvegarde ne remplisse le disque de l’ordinateur au cas ou un disque USB ne serait pas connecté au moment de la sauvegarde.
 ==== Installation de cryptshot.sh et backitup ====
@@ Ligne 254: / Ligne 272: @@
 Pour répéter les tests il faudra probablement enlever (ou remplacer par ''%%000%%'') les fichiers ''%%daily%%'' du répertoire précédent.
-==== Forcer une sauvegarde ====
+==== Forcer une sauvegarde par un nouveau script ====
 Pour forcer la sauvegarde quotidienne, même si elle a déjà été faite plus tôt dans la journée … Créer (encore) un script : ''%%/usr/local/bin/force-cryptshop.sh%%'' et le remplir avec :
@@ Ligne 269: / Ligne 287: @@
 </code>
 On pourra l’appeler en ligne de commande, en phase de tests, et pour sauvegarder les derniers travaux de la journée juste avant de quitter le lieu correspondant.
 ==== Udev : Déclencher la sauvegarde à la connexion du disque usb ====
@@ Ligne 277: / Ligne 296: @@
   * le peupler avec\\
 ''%%ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", RUN+="/etc/cron.hourly/cryptshot-execute"%%''
-  * rechargez les règles udev en utilisant la commande suivante Ou redémarrer) :<code>
+  * Redémarrer ou recharger les règles udev, puis "déclencher" (la redétection?) en utilisant la commande suivante :
-sudo udevadm control --reload-rules
+ <code>
+sudo udevadm control --reload-rules && sudo udevadm trigger
 </code>
   * Tester en connectant un des disques de sauvegarde
-Le fonctionnement peut être capricieux quand le disque est connecté au travers d'un hub thunderbolt. Connecter le disque directement sur un port USB de l'ordinateur.
+Le fonctionnement peut être capricieux quand le disque est connecté au travers d'un hub thunderbolt. Connecter alors le disque directement sur un port USB de l'ordinateur.
-===== Problème connus =====
-Faire et automatiser des sauvegardes, c’est bien ; il faut aussi pouvoir les utiliser. Lorsque le disque USB est connecté, il apparait comme pouvant être moté dans l’espace utilisateur. Il faudra saisir le mot de passe pour l’ouvrir. Tout cela est bien, et nous permettra de consulter nos sauvegardes de n’importe quelle machine (non testé sous Windows ni MacOS); Sauf que …\\
+==== Lancer la sauvegarde à la connexion et la déconnexion de l'utilisateur ====
+L'idée : quand on arrive ou repart d'un lieu de travail, on veut que les sauvegardes soient mises à jour.
-Cela fout le bordel sur la machine qui fait les sauvegardes. - Lorsque l’on ouvre le volume en tant qu’utilisateur (typiquement dans /media/user/monvolume) le script ''%%cryptshot%%'' s’arrête en erreur. Le développeur me dit que ce serait trop insécure de permettre simultanément les accès utilisateur et l’ouverture pour une sauvegarde en cours, elle attendra le prochain ''%%hourly%%''.\\
+Le moyen : placer des scripts adéquat à la connexion ou la déconnexion. Je l'ai fait dans l'interface de configuration de KDE, trouvez le moyen pour votre situation.
- Lorsque l’on “détache” le disque USB, il n’apparait plus comme détecté par le system (les fichiers correspondants sous /dev/disk/*/… ne sont plus présents), alors le script ne peut plus tourner les sauvegardes non plus.
-==== Solutions ====
+Une difficulté : ces scripts sont lancés en tant qu'utilisateur, les sauvegardes doivent être lancées en root.
+se permettre de lancer sertains scripts en tant que root, sans mot de passe (puisque lancés automatiquement) :
+<code>
+sudo visudo  /etc/sudoers.d/mecryptshot
-- Une solution est de déconnecter/reconnecter le disque USB. A défaut d’y penser, on pourrait se retrouver sans sauvegardes pendant quelques jour…
+me ALL=(ALL) NOPASSWD: /usr/local/bin/mecryptshop-force.sh,/usr/local/bin/mecryptshop-lance>
+</code>
+```
+Créer les scripts correspondants :
-- Faire un (autre) script /usr/local/bin/Back-domicile-mount-sh avec :
+Éditer : /usr/local/bin/mecryptshop-force.sh
+<code>
+#!/bin/bash
+sudo echo '000' > /usr/local/etc/cryptshot/lastrun/xadom.daily
+sudo echo '000' > /usr/local/etc/cryptshot/lastrun/alta.daily
+sudo /usr/local/bin/cryptshot-execute
+exec >> "/var/log/cryptshot.log"
+echo "C'était mecryptshot-force.sh" /t
+</code>
+Éditer : /usr/local/bin/mecryptshop-lance.sh
 <code>
 #!/bin/bash
-mkdir /mnt/Monvolume
+sudo /usr/local/bin/cryptshot-execute
-cryptsetup luksOpen --key-file /chemin/de/la/cle.whatever /dev/disk/by-partlabel/Monvolume crypt-Monvolume
-mount --options noatime /dev/mapper/crypt-Monvolume /mnt/Monvolume
+exec >> "/var/log/cryptshot.log"
-read -p " $volume est monté, visiter /mnt puis appuyez sur Enter pour tout refermer"
+echo "C'était mecryptshot-lance.sh" /t
-umount /mnt/Monvolume
-rmdir /mnt/monvolume
-cryptsetup luksClose crypt-Monvolume
 </code>
-Toujours lancer en root, par sudo. Cette ouverture et ce montage ne “détache” pas le disque, et le script reste fonctionnel. Le risque est d'oublier la fenêtre de la console avec la fermeture du montage non faite.
-- proposition par l’auteur du script dans les “issues” [[https://github.com/pigmonkey/cryptshot/issues/8|Continue the script when the volume is already luksOpened ? · Issue #8 · pigmonkey/cryptshot · GitHub]] - non testé
+Ces scripts déclenchent les opérations comme confugurées dans les étapes précédentes.
+==== Consulter les sauvegardes ====
+Là ou je suis, avec KDE, le montage par les outils graphique pose des problèmes. Le démontage quand on ferme le volume n'est pas complet, et il y a une erreur ensuite quand le script essaye de luksopen le volume.
+j'utilise encore des scripts ...
+Sudo est souhaitable pour contrôler l'accès aux sauvegardes, sinon ajuster visudo en conséquence
+On déchiffre le volume, et on le regarde avec mc (c'est mon choix).
+Pour fouiller les sauvegardes plus facilement, tant que mc est ouvert dans la console, utiliser /mnt/<target device> comme chemim dans vos applications graphiques courantes.
+A la fermeture de mc, le volume sera démonté, et les sauvegardes suivantes seront fonctionnelles.
+/usr/local/bin/memount-mydomicile-sh
 <code>
+#!/bin/bash
+ mkdir /mnt/<target device>
+ cryptsetup luksOpen --key-file <chemin/Keyfile> /dev/<target device>  crypt-<target device>
+ mount --options noatime /dev/mapper/crypt-<target device> /mnt<target device>
+ mc /mnt/<target device>
+ umount  /mnt/<target device>
+# rmdir  /mnt/<target device>
+ cryptsetup luksClose crypt-<target device>
+</code>
+===== Problème connus =====
+J'ai eu quelques difficultés à assurer le démontage du volume crypté quand j'utilisais les outils graphiques de KDE pour le consulter. Le chapitre précédent fonctionne adéquatement, mais si vous rencontrez ce genre de problème, le développeur de cryptshot m'a proposé une autres apprche de cette nature. voir [[https://github.com/pigmonkey/cryptshot/issues/8|Continue the script when the volume is already luksOpened ? · Issue #8 · pigmonkey/cryptshot · GitHub]]
+<code>
 if [ -d /mnt/backupdrive ]; then
     rsnapshot -c /path/to/rsnapshot.conf daily
@@ Ligne 319: / Ligne 380: @@
     cryptshot.sh -c /path/to/cryptshot.conf -i daily
 fi
 </code>
+A toutes fiins utiles - non testé
@@ Ligne 330: / Ligne 391: @@
 Merci aux auteurs et contributeurs [[:rsnapshot]], des scripts //cryptshot// et //backitup// [[https://github.com/pigmonkey|pigmonkey]] pour leur patience et leur soutien. Les autres scripts proposés ici ont largement été inspirés par [[https://github.com/pigmonkey/cryptshot/issues/8|ces échanges]].
+Cet aricle reste "en cours de rédaction" en attendant que quelqu'un témoigne de l'avoir utilisé sans y avoir trouvé d'erreur. Si vous y parvenez, pour pourriez enlever ou demande d'enlever l'alerte en haut d'article.
 ===== Voir aussi =====
@@ Ligne 360: / Ligne 421: @@
 ** Incron, comme alternative à Udev (non testé) **\\
-[[https://doc.ubuntu-fr.org/incron|incron [Wiki ubuntu-fr]]]
+ [[:incron|Incron]]
 [[https://www.it-connect.fr/incron-executer-des-actions-selon-des-evenements/|Incron : exécuter des actions selon des événements | Commandes et Système | IT-Connect]]
 ----
+//[[:Contributeurs]] : [[:utilisateurs:LIVIER]].//
-//Contributeurs principaux : [[:utilisateurs/livier|LIVIER]].//

Différences

Outils de la page

Outils du site

Divers