Différences

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

--- tutoriel:sauvegardes_nomades_securisees [Le 08/08/2026, 00:54] – ne pas inventer de tags svp / voir /wiki/recommandations krodelabestiole
+++ tutoriel:sauvegardes_nomades_securisees [Le 08/08/2026, 04:17] (Version actuelle) – [Rsnapshot] livier
@@ Ligne 172: / Ligne 172: @@
 === 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 .
+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.
 <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>
 </code>
-Vérifier l'état de la sauvegarde du fichier entête
-Teste avec le mot de passe,
-<code>
-sudo cryptsetup luksHeaderRestore --header-backup-file /chemin/vers/votre/fichier --test-passphrase
-</code>
-Teste la structure et les slots utilisés
-<code>
-sudo cryptsetup luksDump --header-backup-file /chemin/vers/votre/fichier
-</code>
 ===== Utilisation des scripts =====
@@ Ligne 194: / 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 ====

Différences

Outils de la page

Outils du site

Divers