Re: LinuX : DD / sauvegardes

[Pascal Hambourg <pascal AT plouf.fr.eu.org>]

Le 22/12/2023 à 11:39, culte.org (via linux-31 Mailing List) a écrit :
> > > En revanche, dans cette nouvelle configuration, en cas de soucis sur 
> > > le 1er, je vais être embêté pour DD du 2eme vers le 1er ...
> >
> > Pourquoi serais-tu embêté ? La copie s'arrêtera à la fin du SSD le 
> > plus petit, c'est tout.
>
> La consistance du partitionnement et des données du disque risquent 
> d'être altérées du fait d'une différence de géométrie des matériels ?

Les BIOS et systèmes d'exploitation n'utilisent plus l'adressage CHS lié 
à la "géométrie" (fictive de toute façon) depuis longtemps mais 
l'adressage linéaire (LBA).

Toutefois attention avec le format de partitionnement GPT qui enregistre 
la taille utilisable du disque dans la table de partition et crée une 
table de partition de secours à la fin du disque. Si on clone un disque 
dans un disque de taille différente avec dd, la taille utilisable 
inscrite dans la table de partition ne correspondra pas avec la taille 
réelle du disque, et la table de partition de secours ne sera pas au bon 
emplacement. Cela n'empêche pas Linux d'utiliser les partitions du 
disque, mais peut faire tiquer les programme de gestion des partitions 
comme Gparted qui peuvent proposer de "réparer" ces incohérences, voire 
réparer automatiquement sans rien demander. Donc éviter d'utiliser un 
programme de partitionnement en lecture-écriture sur ce disque.

> > > Est-il possible d'utiliser DD en le limitant à des partition ?
> >
> > Oui mais tout n'est pas dans les partitions comme la table de 
> > partition et le secteur d'amorçage BIOS/legacy principal.
>
> Certes. C'est une de mes craintes, j'ai peur d'omettre des éléments.

Copier un disque ou une partition avec dd a l'avantage d'être simple et 
fiable puisque dd copie tout à l'identique octet par octet. Mais en 
corollaire il a l'inconvénient de copier même les blocs inutilisés qui 
ne contiennent aucune donnée, surtout vers un SSD :
- cela prend plus de temps
- cela occasionne plus d'écritures, usant inutilement les SSD
- un SSD marque tous les blocs écrits comme occupés même s'ils ne 
contiennent aucune donnée utile pour le système , ce qui peut diminuer 
ses performances et son endurance.

Pour ton type d'utilisation l'usure ne devrait pas être un souci car un 
SSD est censé supporter au moins 1000 cycles d'écriture/effacement complets.

Pour réduire le troisième inconvénient, on peut passer les systèmes de 
fichiers au TRIM avec fstrim pour marquer les blocs inutilisés après la 
copie avec dd. Note : fstrim ne fonctionne que sur les systèmes de 
fichiers montés. Pour TRIMer le swap, il faut l'activer avec swapon avec 
l'option --discard.

Pour ne pas copier les blocs inutilisés, on peut utiliser le programme 
partclone au lieu de dd pour copier le contenu utile des partitions une 
par une. Partclone est notamment utilisé par CloneZilla. Cependant la 
table de partition et tout ce qui se trouve en-dehors des partitions 
(comme GRUB pour l'amorçage BIOS) doit être cloné séparément. Pour 
cloner une table de partition DOS ou GPT on peut utiliser le programme 
sfdisk avec l'option --dump.

dd, partclone et clonezilla ont l'inconvénient de ne pas être 
utilisables pour cloner des partitions en cours d'utilisation (montées).
rsync n'a pas cet inconvénient, de même qu'il permet d'exclure des 
fichiers et répertoires qu'il n'est pas nécessaire de sauvegarder 
(exemple : logs, fichiers temporaires) et de n'écrire que les 
différences dans une sauvegarde existante.

Par contre rsync (ou tout autre programme fonctionnant sur un système de 
fichiers monté) n'est pas utilisable pour cloner un système utilisant 
LVM car il ne serait pas possible d'activer simultanément deux VG ayant 
le même nom et les mêmes UUID. Je soupçonne qu'il en est de même avec le 
système de fichiers Btrfs.