Qu’est ce que tu entends par optimisation en matière de backup?
L’expression “la meilleure” est une forme de superlatif relatif qui implique une comparaison au moyen d’un critère d’optimisation appelé aussi fonction de coût. L’optimisation consiste à déterminer la solution qui minimise cette fonction de coût.
Optimisation (mathématiques)
En clair, si tu prèfères : quel est ton critère de comparaison des différentes solutions ?
Ok pour la définition je m’en souviendrais… 
Mais bon en clair je n’ai aucun critère de comparaison entre les trois étant donné que je ne les ai jamais utilisé ni fait de backup de toute ma carrière d’informaticien amateur à domicile (eh ouais je sais c’est pas bien…), à part du copier/coller bête et simple…
Là étant donné que je vais utiliser du BTRFS, les snapshots c’est bien mais ce ne sont pas des backups, si le système de fichiers merde pour X raison, au revoir les données, snapshots ou pas… Donc en plus de la fonction snapshots, je vais me mettre à faire des backups à intervalle prédéfinis (logiciels ou script en CLI je m’en fiche).
J’aimerai aussi éventuellement de préférence que ce soient des backups incrémentaux.
Et enfin avec ces backups (ou séparément peut-être, je ne sais pas encore comment ça fonctionne donc j’ai de la lecture en perspective), je souhaite pouvoir faire une/des iso de mon système, avec lesquelles je pourrai réinstaller à l’identique, déployer sur d’autres machines une copie conforme de mon installation… Je ne sais pas si on peut également faire des iso incrémentales…?
Voilà c’est à peu près tout pour l’instant.
Note : je n’y connais pas grand-chose non plus en matière de sauvegarde.
Non mais ils peuvent faire partie d’une stratégie de sauvegarde, en figeant les fichiers le temps de réaliser la sauvegarde pour éviter toute incohérence.
C’est un critère, non ?
Ça élimine d’emblée dd. J’ignore si clonezilla peut le faire.
Ah, oui, je n’avais pas répondu à ton message précédent concernant ces ISO. Pourquoi veux-tu créer des images ISO ? Ce système de fichiers n’est utile que pour les supports optiques. Si tu veux parler des images disque comme celles qu’on peut créer avec dd ou clonezilla, cela n’a rien à voir avec une image ISO.
rsync fonctionnant sur les fichiers et non les disques ou partitions, il ne suffit pas à cloner un système entier.
Oui bien sûr, mais au début j’avais compris qu’un snapshot était l’équivalent d’un backup sans le compromis de la taille, et en creusant le sujet j’ai compris que ce n’était pas le cas… Pour ma part je suis vraiment débutant dans tout ce qui est snapshot, backup donc je creuse le sujet pour comprendre les rouages et les différentes possibilités.
De plus j’ai de plus en plus de fichiers “photos” (.jpeg) qui deviennent corrompus avec le temps, soit je ne peux plus les ouvrir soit il ne reste que des bouts de photos, et curieusement je n’ai pas de problèmes avec les autres types de fichiers…
Est-ce que c’est le DD qui se fait la malle en douceur, ou bien le fait que depuis que j’ai ce laptop j’ai réinstallé pas mal de fois, avant sur Windows puis sur Linux, et pour sauver mon DATA j’ai du transférer celui-ci sur un autre DD externe pui ramener le tout après à coups de copier/coller… Aucune idée, mais ça m’emmerde sérieusement. Donc il faut que je fige certains vieux trucs en une ou deux copies.
C’est vrai j’ai parlé au pluriel mais en réalité je pense peut-être faire un ou deux, voir trois ISO de mon système que je garderai de côté au cas où j’aurai besoin de réinstaller un jour, ou voir même me servir de cet ISO pour monter mes VM sous virtualbox… Je voudrais un ISO car je suis sous Sid, et quand je réinstalle ou monte une VM Debian, il me faut à chaque fois monter une Stable d’abord, puis ensuite faire un upgrade vers Sid, puis enfin ramener toute la config à l’identique à celle qui me sert d’hôte.
Donc l’idée serait de faire une image de mon système qui serait installable comme un ISO Debian officiel, mais une mouture personnelle…
Par contre je me fiche de conserver une image du partitionnement et tout le reste si c’est à ça que tu pensais.
Maintenant si on peut faire ça avec un autre format qu’ISO ça m’est égal aussi. Et si en plus cette image peut être incrémentale alors là c’est le pied.
Cela dépasse largement le cadre de mes connaissances. Tu devrais peut-être créer un autre sujet avec un titre adéquat qui attire des contributeurs plus expérimentés en sauvegarde et restauration, parce qu’on s’est pas mal éloigné du problème initial.
Oui c’est ce que je vais faire parce que là je suis même sorti du sujet inital depuis les quelques derniers messages qu’on a échangé et ça n’a rien à avoir avec le sujet. Mais je vais d’abord chercher de mon côté quand même.
En tous cas merci pour tout Pascal.
Bon pour revenir après quelque temps de lecture et d’expérimentations sur les différentes possibilités avec LUKS, BTRFS (et éventuellement LVM), j’ai une nouvelle question à laquelle je ne trouve pas de réponse.
J’ai donc essayé plusieurs schémas d’installation dont le suivant :
- création d’un conteneur LUKS sur le disque /dev/sda
- ouverture du conteneur
- création d’une table de partition GPT sur /dev/mapper/sda_crypt
- partitionnement de /dev/mapper/sda_crypt (swap, btrfs, …)
En fait pour être plus précis, ce que je veux faire ici c’est la même chose que de faire un partitionnement avec LVM sur conteneur LUKS, mais sans la couche LVM…
Cependant il semble que ce soit impossible à faire fonctionner par la suite…? Quelqu’un peut confirmer que c’est un cul-de-sac?
Tous les types de périphériques bloc ne sont pas partitionnables, c’est-à-dire que le noyau n’y recherche pas une table de partition. Les ensembles RAID logiciels ne sont devenus partitionnables qu’à partir du noyau 2.6. Les volumes logiques LVM, les fichiers images “montés” en loop (man losetup), et, je le crains, les volumes chiffrés, ne sont pas partitionnables.
Néanmoins, des commandes comme partx (paquet util-linux) ou kpartx (paquet éponyme) peuvent permettent de faire reconnaître des partitions sur n’importe quel type de périphérique bloc. A noter que kpartx utilise le device-mapper pour “activer” les partitions, comme LVM pour activer les volumes logiques. Mais je ne vois pas l’intérêt par rapport à LVM, et de surcroît il faudrait créer ton propre script d’init (et l’intégrer à l’initramfs si la racine est sur cette structure) pour activer ces partitions automatiquement a démarrage.
Donc en fait on peut faire d’une partition, quitte à ce qu’elle occupe tout le disque, un volume chiffré, mais il y a peu de chances que l’on puisse partitionner un volume chiffré.
En fait comme je l’ai dit plus, j’essaie de me passer de la couche LVM puisque j’ai l’intention d’utiliser BTRFS et dans ce cas le partitionnement classique ne m’est d’aucun intérêt (mis à part pour la swap ; je laisse de côté pour l’instant les partitions bios-boot et esp, si j’arrive à faire marcher mon schmilblick pour deux partition au sein d’un conteneur chiffré, ça marchera aussi pour quatre…).
Donc en fait, dans le shell de l’installateur Debian, je chiffre le disque /dev/sda, je l’ouvre avec cryptsetup, je crée une table de partitions GPT sur le volume chiffré /dev/mapper/sda_crypt, puis je crée les partitions dont j’ai besoin et je retrouve donc avec le schéma final (exemple de retour blkid ):
- dev/sda type=CRYPTO_LUKS
- dev/mapper/sda_crypt (volume chiffré sur lequel vient la table GPT)
- dev/mapper/sda_crypt1 (partition 1 - par exemple swap)
- dev/mapper/sda_crypt2 (partition 2 - par exemple btrfs)
…
Le truc évidemment c’est qu’avant de monter les chemins dans target pour lancer l’installation je veux m’assurer que le partitionnement fonctionne, donc j’essaie de fermer le volume chiffré avec cryptsetup luksClose… Mais là ça ne marche pas, cryptsetup est incapable de fermer le volume chiffré en se plaignant…
J’avais déjà essayé de poursuivre une installation précédente sur le même schéma en ignorant ça, mais ça s’est résulté sur le fait qu’il était impossible au redémarrage de monter les partition.
L’équivalent avec la couche LVM sont les commandes vgscan et vgchange qui permet d’activer ou désactiver les volumes logiques…