✎ tutoriel:sauvegardes_nomades_securisees [Wiki ubuntu-fr]

Vous affichez une ancienne révision du document ! Si vous l'enregistrez, vous créerez une nouvelle version avec ce contenu.

Creating directory /srv/www/doc.ubuntu-fr.org/htdocs/data/tmp/captcha/2025-07-25 failed

{{tag>LTS_22.04 sauvegarde disque_USB chiffrement rsnapshot cryptsetup tutoriel BROUILLON}}

====== Sauvegardes nomades sécurisées pour laptop ======

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.

Un sauvegarde doit donc être faite sur des disques externes USB chiffrés, connectés régulièrement, en suivant une programmation adéquate (daily-weekly …)

Il devrait y avoir (au moins) deux “lieux” avec chacun un disque de sauvegardes qui ne bouge pas. L’ordinateur se promenant de l’un à l’autre (typiquement, ''%%domicile%%'' et ''%%bureau%%''). Au moins une sauvegarde serait alors à l’abri en cas d’incendie ou de vol. Cela pourrait toutefois être insuffisant face aux risques d’agressions militaires majeures, qui se produisent pourtant.

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

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.

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”

===== Utiliser une partition chiffrée =====

Nous utiliserons les partitions “LUKS” pour leur (relative) simplicité et la possibilité de définir plusieurs “clés” (fichiers ou bonmots-de-passe) permettant le déchiffrement.

Avant de confier la manipulation de conteneurs LUKS à des scripts que nous devrons configurer, apprenons à les manipuler à la main.

==== Avertissements : ====

* l’utilisation de partitions chiffrées est un risque supplémentaire pour les données ; celui de la perte d’accès, par perte des mots de passe, altération des entêtes du volume etc. Soyez responsable.
  * 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%%'')
 <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 ;-)**

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

<note tip>On peut aussi loguer des informations utiles en ajoutant quelques éléments dans les scripts :

- Ajouter une ligne `echo "$(date '+%Y-%m-%d %H:%M:%S') étape d'execution" >> /var/log/cryptshot.log`

- Ajouter `| tee -a /var/log/cryptshot.log` à la suite d'un message du script  `echo 'message.' | tee -a /var/log/cryptshot.log`

</note>

==== Quelques points de repères pour comprendre le système : ====

* dès la connexion du disque en USB plusieurs points de montage apparaissent :
    - /dev/sdXx (genre sdc1) mais ce point de montage changera facilement si un autre USB est connecté avant, ou autre raison.
    - Une série de liens symboliques vers ce premier point sont proposés dans ''%%/dev/disk%%'' classés par sous répertoire celon le type d’identification, par uuid ou label, pour les disques ou les partitions. Je préfères ''%%/dev/disk/by-partlabel/%%'', plus visuel dans la préparation des commandes et des scripts, et les autres sont aussi fonctionnels.
    * Désormais nous utiliserons l’expression ''%%/dev/<target device>%%'' pour désigner celui que vous choisirez d’utiliser.
  * lorsque une partition est déchiffrée avec une clé, sous le nom “monVolume”, elle apparait dans ''%%/dev/mapper/monVolume%%''
  * pour l’utiliser, il faudra la formater (une seule fois hein, sous peine de perdre les donées !) Utiliser ext4 typiquement, surtout pas vfat ou un autre format qui ne supporte pas les liens en durs, nécessaires à rsnapshot.
  * puis la monter (dans ''%%/mnt/monVolume%%'' typiquement). Ce montage est persistant, tant que le volume n’a pas été démonté, par une commande, un script ou l’arrêt de l’ordinateur.

==== Préparer la partition chiffrée pour la sauvegarde ====

Ces opérations ne sont à faire que une seule fois, à la création du volume chiffré.

=== Créer et repérer la partition à chiffrer ===

Ici ont fait bien attention à ne pas bousiller une partion qui nous est utile !! J’utilise pour ma part une partition unique sur un disque USB …mais vous faites bien ce que vous voulez.

Outils : gestionnaire de partitions KDE, ''%%$lsblk%%'' , viste des sous répertoire de ''%%/dev/disk%%''. Comme indiqué plus haut, nous utiliserons ici l,expression ''%%/dev/<target device>%%'' pour désigner la partition à chiffrer.

=== Effacer la partition à chiffrer ===

Il est recommandé d’effacer vraiment la partition, au moins le système de fichiers. ''%%$ wipefs -a <target device>%%''\\
Si vous éprouvez le besoin de supprimer aussi radicalement les anciennes données du disque (qui seront écrasées par les sauvegardes chiffrées) ''%%cat /dev/zero > <target device>%%''. En mode parano, qui prendra du temps : ''%%cat /dev/urandom >  <target-device>%%''

=== Chiffrer la partition ===

Créer un conteneur LUKS :\\
Choisir un <html><Bonmot-de-passe></html> et le mémoriser, le mettre dans un coffre (à la banque, ou dans un bon gestionaire de mot de passe comme Keepasxc, mon choix). ensuite, lancer la commande :

<code bash>
 cryptsetup luksFormat <target device>
</code>
=== Formater la partition chiffrée ===

D’abord l’ouvrir une première fois

<code bash>
cryptsetup -v luksOpen /dev/<target device> monVolume
</code>
Ensuite, on pourra la formater sur /dev/mapper/monVolume. Ici l’expression MonVolume sera ce que vous voulez. Plus part, des scripts définiront cette valeur pour vous.

<code bash>
mke2fs -t ext4 -L monVolume /dev/mapper/monVolume
</code>
=== Création du point de montage ===

<code bash>
mkdir /mnt/monVolume 
</code>
==== Précautions complémentaires indispensables ====

=== Montage et démontages des volumes chiffés ===

<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é :

<code bash>
cryptsetup -v luksOpen /dev/<target device> monVolume
</code>
  * Ouvrir la partition chiffrée, avec un fichier clé (voir plus bas):

<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

<code bash>
mount -v /dev/mapper/monVolume /mnt/monVolume 
</code>
  * Démontrer puis fermer la partition chiffrée

<code bash>
umount -v /dev/mapper/monVolume 
    # ou
umount -v /mnt/monVolume 
</code>
  * Fermer la partition chiffrée

<code bash>
cryptsetup -v luksClose monVolume
</code>
> Les scripts que l’on utilisera bientôt s’attendent à les trouver bien fermés.

=== Gérer les clés du conteneur LUKS ===

Pour approfondissements, voir :

<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.
  - un “bon-mot de passe” que vous seul pourrez utiliser pour ouvrir le conteneur en dehors de la procédure automatisée.

Voir le nombre de clés enregistrées, et autres information de “header”

<code bash>
cryptsetup luksDump /dev/<target device>
</code>
Ajouter un “bon-mot de passe” à un conteneur

<code bash>
# cryptsetup luksAddKey  /dev/<target device> 
Enter any passphrase: (un mot de passe existant du volume)
Enter new passphrase for key slot: 
Verify passphrase: 
</code>
Ajouter une keyfile à un conteneur ayant dejà un “bon-mot de passe”

<code bash>
# cryptsetup luksAddKey  /dev/<target device> masterkeyfile
Enter any passphrase: (un mot de passe existant du volume)
</code>
=== Sauvegarder l’entête du conteneur ===
<note important>
Cet entête intégral est indispensable à l’ouverture du conteneur.</note> 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 .

luksHeaderBackup /dev/<html><target device></html> –header-backup-file <html><file></html>

luksHeaderRestore /dev/<html><target device></html> –header-backup-file <html><file></html>

===== Utilisation des scripts =====

Faire des tests pour vérifier ce qui se passe au fur et à mesure…

Attention à la gestion des droits. Vous voudrez que vos scripts soient exécutables par root, pas par les autres utilisateurs en général. Vous voudrez pouvoir créer ou ajuster un script, pas forcément en tant que root avec la ligne de commande. Mes solutions ne seraient peut être pas les votres …

==== Rsnapshot ====

Voir la page dédiée [[https://doc.ubuntu-fr.org/rsnapshot|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.

==== Installation de cryptshot.sh et backitup ====

Cryptshot permet de déchiffrer la partition des sauvegardes pendant qu’elles doivent exécutées, typiquement avec rsnapshot.

Backitup permet de programmer l’exécution des sauvegardes de façon adaptée à l’intermitance de la connexion du disque USB de sauvegarde.

* Aller chercher les scripts ici : https:%%//%%github.com/pigmonkey/cryptshot et ici : https:%%//%%github.com/pigmonkey/backitup/blob/master/backitup.sh
  * Les déposer dans un répertoire faisant partie du PATH, accessible par root, typiquement : /usr/local/bin .\\

* Les recopier en ajoutant l’extensio "*.origin)" pour sauvegarde et pouvoir ajuster les scripts eux mêmes.

==== Configuration de cryptshot ====

* J’ai un moment été confus avec les “UUID” qui me semblaient changer, J’ai changé pour “PARTUUID” dans le script (en remplaçant toutes les occurences) qui me semblaient plus claires. C’est un fork probablement inutile ; faites comme vous voulez et soyez responsables !
  * La configuration peut se faire dans le script, mais si vous voulez plusieurs sauvegardes, sur des disques usb différents (dans des lieux différents) avec chacun ses identifiants de partition <html><target device></html>, il faudra mettre les configurations correspondantes dans, typiquement, /usr/local/etc/cryptshot/[domicile/bureau].conf .
  * Créer ses fichiers tout de suite avec les droits adéquats. Les remplir avec les variables du scrit, typiquement :

<code>
## indiquer la partition destinataire de la sauvegarde
UUID="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" # pour la version originale du script
# PARTLABEL="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" # pour ma version modifiée ...  
## Indiquer le fichier clé
KEYFILE="/chemin/votre fichier cle"  
## la base du point de montage
MOUNTROOT="/mnt/"
## option pour supprimer la trace du répertoire destinataire des sauvegardes à la fin du script
REMOVEMOUNT=1
## Indiquer la commande de sauvegarde. 
## On utilise ici un fichier de configuration spécifique par lieu de sauvegarde. ### En fait, seule la seule ligne qui doit obligatoirement changer est : snapshot_root /mnt/<target device>/rsnapshot/   
BACKUP="/usr/bin/rsnapshot -c /usr/local/etc/rsnapshot/domicile.conf"

</code>
  * Tester dans un terminal en utilisant le format de commande que l’on retrouvera plus tard dans le script. ''%%-c%%'' désigne le fichier de configuration avec les variables à utiliser (qui vont surcharger celles inscrites dans le script) . ''%%-i%%'' sera la variable passée à rsnapshot (ici Daily pour la sauvegarde quotidienne) ''%%/usr/local/bin/cryptshot.sh -c /usr/local/etc/cryptshot/domicile.conf -i daily%%''
  * Il y a différents paramètres à définir, et on peut avoir à tester la configuration quelques fois ; mes deux astuces
    * mettre ''%%set -x%%'' en début de script afin de voir les commandes qui passent quand on lance le script en console (retirer ensuite)
    * Cryptshot se lance avec le paramètre -i, l’argument est ensuite passé à rsanpshot. Pour les sauvegardes quotidienne on fera : ''%%-i daily%%'' pour les tests on pourra mettre ''%%-i configtest%%'' ou ''%%"-i -t daily"%%'' et regarder ce que le script renvoie dans la console.
    * Quand cette commande produit effectivement une sauvegarde adéquate sur disque USB, gardez là, et poursuivez la mise en place des autres scripts

==== Configuration de backitup.sh ====

Backiptup sera appelé par le script suivant et lancera le script précédent si sauvegarde mérite de tourner : si elle date de plus que le délai indiqué comme souhaitable.\\
Dans mon cas ces délais sont ceux de mon rsnapshot : daily, weekly et monthly

Tester dans un terminal en utilisant le format de commande que l’on retrouvera dans le script suivant :

<code>
  /usr/local/bin/backitup.sh -q -l /usr/local/etc/cryptshot/lastrun/domicile.daily -b "/usr/local/bin/cryptshot-domicile.sh -c /usr/local/etc/cryptshot/domicile.conf -i daily" -p DAILY
</code>
  * ''%%-q%%'' demande “quiet” au script\\

* ''%%-l%%'' indique le fichier ou les dates des dernières sauvegardes sont enregistrés. Créer ce (ces, dans le script suivant nous verrons que nous en avons besoin de six) fichier(s) en faisant toujours attention aux droits.
  * -p indique la fréquence souhaitée pour cette sauvegarde
  * Quand cette commande produit effectivement une nouvelle sauvegarde quotidienne adéquate, gardez là, et poursuivez la mise en place des derniers scripts

==== Vérifier toutes les heures si des sauvegardes doivent être lancées ====

* Créer le script adéquat ici dans /etc/cron.hourly/cryptshot-execute (avec droit d’exécution)
  * Le remplir avec :

<code>
#!/bin/bash
## Pour voir le déroulement du script en console :
# set -x
## domicile
 /usr/local/bin/backitup -q -l /usr/local/etc/cryptshot/lastrun/domicile.monthly -b "/usr/local/bin/cryptshot -c /usr/local/etc/cryptshot/domicile.conf -i monthly" -p MONTHLY
 /usr/local/bin/backitup -q -l /usr/local/etc/cryptshot/lastrun/domicile.weekly -b "/usr/local/bin/cryptshot -c /usr/local/etc/cryptshot/domicile.conf -i weekly" -p WEEKLY
 /usr/local/bin/backitup -q -l /usr/local/etc/cryptshot/lastrun/domicile.daily -b "/usr/local/bin/cryptshot -c /usr/local/etc/cryptshot/domicile.conf -i daily" -p DAILY
## bureau
 /usr/local/bin/backitup -q -l /usr/local/etc/cryptshot/lastrun/bureau.monthly -b "/usr/local/bin/cryptshot -c /usr/local/etc/cryptshot/bureau.conf -i monthly" -p MONTHLY
 /usr/local/bin/backitup -q -l /usr/local/etc/cryptshot/lastrun/bureau.weekly -b "/usr/local/bin/cryptshot -c /usr/local/etc/cryptshot/bureau.conf -i weekly" -p WEEKLY
 /usr/local/bin/backitup -q -l /usr/local/etc/cryptshot/lastrun/bureau.daily -b "/usr/local/bin/cryptshot -c /usr/local/etc/cryptshot/bureau.conf -i daily" -p DAILY
</code>
Créer les fichiers correspondants dans ''%%/usr/local/etc/cryptshot/lastrun/%%''

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 à la connexion du disque USB ====
<note warning>Ceci n'a pas fonctionné chez moi, suis passé à une autre approche </note>

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 :

<code>
#!/bin/bash
## Pour voir le déroulement du script en console :
# set -x
 
echo '000' > /usr/local/etc/cryptshot/lastrun/domicile.daily
echo '000' > /usr/local/etc/cryptshot/lastrun/bureau.daily

/etc/cron.hourly/cryptshot-execute
</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 ====
<note warning>ceci n'a pas fonctionné chez moi, suis passé à une autre appriche </note>

Cela passe par la création d’une règle udev personnalisée. La règle simple ci dessous détectera toute nouvelle connexion sur un port usb, puis lancera le script de sauvegarde. Si le périphérique connecté est un des disques usb prévu pour la sauvegarde, elle aura lieu ; sinon le script ne trouvera rien a faire.

* Créer le fichier ''%%/etc/udev/rules.d/10-custom.rules%%'' en tant que root
  * le peupler avec\\
''%%ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", RUN+="/etc/cron.hourly/cryptshot-execute"%%''
  * Redémarrer ou recharger les règles udev, puis "déclencher" (la redétection?) en utilisant la commande suivante :
 <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.

==== Udev : Déclencher la sauvegarde à la connexion du disque usb ====

Cela passe par la création d’une règle udev personnalisée. La règle simple ci dessous détectera toute nouvelle connexion sur un port usb, puis lancera le script de sauvegarde. Si le périphérique connecté est un des disques usb prévu pour la sauvegarde, elle aura lieu ; sinon le script ne trouvera rien a faire.

* Créer le fichier ''%%/etc/udev/rules.d/10-custom.rules%%'' en tant que root
  * le peupler avec\\
''%%ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", RUN+="/etc/cron.hourly/cryptshot-execute"%%''
  * Redémarrer ou recharger les règles udev, puis "déclencher" (la redétection?) en utilisant la commande suivante :
 <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.

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

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.

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

me ALL=(ALL) NOPASSWD: /usr/local/bin/mecryptshop-force.sh,/usr/local/bin/mecryptshop-lance>
</code>
```
Créer les scripts correspondants :

É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 
sudo /usr/local/bin/cryptshot-execute

exec >> "/var/log/cryptshot.log"
echo "C'était mecryptshot-lance.sh" /t
</code>

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/XaDomicile-2024-partition
# rmdir /mnt/XaDomicile-2024-partition
 cryptsetup luksClose crypt-<target device>
</code>

===== 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 …\\

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%%''.\\
 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 solution est de déconnecter/reconnecter le disque USB. A défaut d’y penser, on pourrait se retrouver sans sauvegardes pendant quelques jour…

- Faire un (autre) script /usr/local/bin/Back-domicile-mount-sh avec :

<code>
#!/bin/bash
mkdir /mnt/Monvolume
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
read -p " $volume est monté, visiter /mnt puis appuyez sur Enter pour tout refermer"
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é

<code>

if [ -d /mnt/backupdrive ]; then
    rsnapshot -c /path/to/rsnapshot.conf daily
else
    cryptshot.sh -c /path/to/cryptshot.conf -i daily
fi

</code>

===== Conclusion =====

Il est prudent, dès lors qu'on utilise un ordinateur portable, de gérer ses sauvegardes, à plusieurs endroits et de façon chiffrée.

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

===== Voir aussi =====

[[:sudo|sudo]]

[[:rsnapshot|rsnapshot]]

[[:cryptsetup|cryptsetup]]

[[https://github.com/pigmonkey/cryptshot|GitHub - pigmonkey/cryptshot: Open and mount a LUKS volume before performing a backup with rsnaphot]]

[[https://github.com/pigmonkey/backitup|GitHub - pigmonkey/backitup: Execute a user-specified command if a certain amount of time has passed.]]

[[https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions|FrequentlyAskedQuestions · Wiki · cryptsetup / cryptsetup · GitLab]]

[[https://www.thegeekstuff.com/2016/03/cryptsetup-lukskey/|10 Linux cryptsetup Examples for LUKS Key Management (How to Add, Remove, Change, Reset LUKS encryption Key)]]

[[https://www.val-r.fr/geek/os/linux/creer-et-utiliser-une-partition-chiffree-avec-luks-sous-linux/|Créer et utiliser une partition chiffrée avec LUKS sous Linux | Valérian REITHINGER]]

[[https://fr.linux-console.net/?p=140|Comment utiliser Udev pour la détection et la gestion des périphériques sous Linux]]

**Quoi sauvegarder**\\
[[wpfr>Sauvegarde_%28informatique%29|Sauvegarde (informatique)]]

[[:sauvegarde|sauvegarde]]

[[:tutoriel/sauvegarder_home|tutoriel sauvegarder son “home”]]

** Incron, comme alternative à Udev (non testé) **\\

[[: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 principaux : [[:utilisateurs/livier|LIVIER]].//

Merci de recopier le code ci-contre pour prouver que vous êtes humain : R J D B C Merci de laisser ce champ vide :

Résumé

Note : En modifiant cette page, vous acceptez que le contenu soit placé sous les termes de la licence suivante : CC Paternité-Partage des Conditions Initiales à l'Identique 3.0 Unported