Vous n'êtes pas identifié(e).
Pages : 1
Dernière modification par jarek (10-08-2023 15:42:43)
En ligne
Les options passées à rsync ici servent à conserver toutes les propriétés des fichiers (propriétaire, groupe, droits, attributs étendus, etc.) et à afficher la progression de la copie.
En ligne
En ligne
Les options supplémentaires données sur le wiki sont à mon avis un exemple de cargo cult, tu peux les ignorer.
En ligne
Dernière modification par jarek (11-08-2023 16:21:18)
En ligne
Si le support de destination est au moins aussi grand que celui d’origine, tu peux bien utiliser dd pour la copie du disque entier
A condition que les tailles de secteur logique (512 ou 4096) soient identiques. Et si les tailles des disques ne sont pas identiques au secteur près, la table de partition de secours GPT ne sera pas au bon endroit (elle doit être dans les derniers secteurs du disque), les programmes de partitionnement le détectent généralement et proposent de le corriger.
Les options supplémentaires données sur le wiki sont à mon avis un exemple de cargo cult, tu peux les ignorer.
conv=notrunc,noerror n'est utile que pour copier ce qui peut l'être depuis un support qui a des blocs défectueux illisibles.
Par contre bs=4096 est utile. La taille de bloc par défaut (512) peut fortement réduire le débit effectif. 4096 est la taille minimum qui permet d'atteindre le débit nominal dans mon expérience. Par comparaison cp utilise une taille de bloc de 128 Kio. Je mets bs=1M pour être tranquille.
Le `sync` c’est pour t’assurer que le prompt ne te rend pas la main avant que la copie soit réellement complète, ce n’est pas strictement nécessaire.
Je n'ai pas encore vu la moindre preuve objective de sa nécessité lors du transfert vers un périphérique bloc (et non vers un fichier normal, qui va transiter par le cache de page). Pour le coup ça ressemble aussi à du cargo cult.
Dernière modification par raleur (13-08-2023 08:38:21)
Il vaut mieux montrer que raconter.
Hors ligne
vv222 a écrit :Le `sync` c’est pour t’assurer que le prompt ne te rend pas la main avant que la copie soit réellement complète, ce n’est pas strictement nécessaire.
Je n'ai pas encore vu la moindre preuve objective de sa nécessité lors du transfert vers un périphérique bloc (et non vers un fichier normal, qui va transiter par le cache de page). Pour le coup ça ressemble aussi à du cargo cult.
Je l’utilise quand je bosse avec des supports amovibles (clés USB ou périphériques externes), pour m’assurer de ne pas débrancher le périphérique avant que la copie soit effectivement terminée. Comme je ne travaille pas souvent avec dd, je ne suis pas certain que ce soit utile dans ce cas.
En ligne
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par raleur (14-08-2023 10:19:55)
Il vaut mieux montrer que raconter.
Hors ligne
C'est tout ?
Tu trouves que c'est trop simple, tu en veux plus ?
Il y a aussi des identifiants uniques utilisés par systemd/dbus (/etc/machine-id, /var/lib/dbus/machine-id) mais je ne sais pas à quoi ils servent ni si ça vaut le coup de les modifier.
Dernière modification par raleur (14-08-2023 10:17:56)
Il vaut mieux montrer que raconter.
Hors ligne
Tu trouves que c'est trop simple, tu en veux plus ?
N'en jettes plus, la cour est pleine
Je vais ensuite essayer rsync, à titre ludique uniquement (maintenant que j'ai un hdd disponible dans le PC).
L'idée de vv222 était finalement aussi simple qu'un "simple" dd.
Il vaut mieux montrer que raconter.
Hors ligne
. . . n'installe pas le chargeur d'amorçage...
Ha ça j'avais pas vu.
Pour l'instant je me contente de sauvegarder avec back in time.
Rsync attendra un peu, j'ai toute la vie devant moi . . .
Pages : 1