Différences

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

--- tutoriel:sauvegardes_nomades_securisees [Le 16/02/2025, 02:02]
livier [Consulter les sauvegardes]
+++ tutoriel:sauvegardes_nomades_securisees [Le 19/02/2025, 18:10] (Version actuelle)
bcag2 [Udev : Déclencher la sauvegarde à la connexion du disque usb] suppr notes qui n'apporte rien (pas de version ni contexte !)!
@@ Ligne 260: / Ligne 260: @@
 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 ====
+==== Forcer une sauvegarde par un nouveau script ====
-<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 :
@@ Ligne 277: / Ligne 276: @@
 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 ====
@@ Ligne 306: / Ligne 290: @@
   * 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.
@@ Ligne 376: / Ligne 360: @@
 ===== 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 …\\
+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]]
-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
@@ Ligne 409: / Ligne 368: @@
     cryptshot.sh -c /path/to/cryptshot.conf -i daily
 fi
 </code>
+A toutes fiins utiles - non testé
@@ Ligne 420: / Ligne 379: @@
 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 =====