[Raspberry] sauvegarde SDcard avec dd

Le
Geo Cherchetout
Re-bonjour,

dd est parfait pour cloner la carte SDHC de ma raspberry mais ce qui me
chagrine c'est que la dite carte SDHC est de capacité très supérieure
(32GiB) à ce qu'elle contient réellement :

$ df -h
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/root 29G 2,9G 25G 11% /
devtmpfs 459M 0 459M 0% /dev
tmpfs 464M 184K 463M 1% /dev/shm
tmpfs 464M 41M 423M 9% /run
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 464M 0 464M 0% /sys/fs/cgroup
/dev/mmcblk0p1 253M 52M 201M 21% /boot
log2ram 30M 2,2M 28M 8% /var/log
tmpfs 93M 0 93M 0% /run/user/1000

Le fichier image produit par dd sera donc de taille inutilement grande, et
l'opération inutilement longue. Comment limiter cette taille sans rien
perdre d'utile ? Je ne sais pas si les données sont entassées au début - si
cela a un sens - du contenant, ou dispersées dans ce vaste espace
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas George
Le #26530737
Geo Cherchetout , dans le message écrit :
dd est parfait pour cloner la carte SDHC de ma raspberry mais ce qui me
chagrine c'est que la dite carte SDHC est de capacité très supérieure
(32GiB) à ce qu'elle contient réellement :

Donc dd est loin d'être parfait. En fait, il est même très médiocre.
Le fichier image produit par dd sera donc de taille inutilement grande, et
l'opération inutilement longue. Comment limiter cette taille sans rien
perdre d'utile ?

Il faut commencer par le commencement : préciser ce qui est utile pour
tes besoins précis. À quoi va servir ce clone ?
Je ne sais pas si les données sont entassées au début - si
cela a un sens - du contenant, ou dispersées dans ce vaste espace...

Très probablement pas. C'est un système de fichiers : on écrit là où il
y a de la place, et quand un fichier est supprimé on libère l'espace
correspondant. Il est possible qu'au commencement de l'utilisation
l'espace soit utilisé en priorité au début, mais ça ne va pas durer.
De plus, l'espace libéré n'est pas effacé, donc les données sont
toujours là, et vont prendre de la place dans l'image.
Geo Cherchetout
Le #26530746
Le 09/11/2019 20:00, *Nicolas George* a écrit :
Geo Cherchetout , dans le message écrit :
dd est parfait pour cloner la carte SDHC de ma raspberry mais ce qui me
chagrine c'est que la dite carte SDHC est de capacité très supérieure
(32GiB) à ce qu'elle contient réellement :

Donc dd est loin d'être parfait. En fait, il est même très médiocre.
Le fichier image produit par dd sera donc de taille inutilement grande,
et l'opération inutilement longue. Comment limiter cette taille sans
rien perdre d'utile ?

Il faut commencer par le commencement : préciser ce qui est utile pour
tes besoins précis. À quoi va servir ce clone ?

Ce clone, réalisé alors que tout marche bien, servirait à restaurer système
et données en cas de défaillance de la carte SDHC actuelle.
Je ne sais pas si les données sont entassées au début - si cela a un
sens - du contenant, ou dispersées dans ce vaste espace...

Très probablement pas. C'est un système de fichiers : on écrit là où il y
a de la place, et quand un fichier est supprimé on libère l'espace
correspondant. Il est possible qu'au commencement de l'utilisation
l'espace soit utilisé en priorité au début, mais ça ne va pas durer.
De plus, l'espace libéré n'est pas effacé, donc les données sont toujours
là, et vont prendre de la place dans l'image.

Pour regrouper un peu les données, il est peut-être possible de
redimensionner la grosse partition, celle de 29,5 GiB ? Avec la commande
resize2fs ? Si je peux la ramener, disons, à 7 GiB, l'image globale obtenue
avec dd n'atteindra pas 8 GiB.
Ma question devient : Puis-je redimensionner une partition d'un système
vivant depuis sa propre ligne de commande ?
Nicolas George
Le #26530747
Geo Cherchetout , dans le message écrit :
Ce clone, réalisé alors que tout marche bien, servirait à restaurer système
et données en cas de défaillance de la carte SDHC actuelle.

Je m'en doutais. Pour l'essentiel du système, des fichiers tar sont un
bien meilleur choix.
La seule chose utile qu'une image embarque que des tarballs ne peuvent
pas embarquer, c'est le bootloader. Je ne sais pas comment marche le
bootloader sur ARM.
Pour regrouper un peu les données, il est peut-être possible de
redimensionner la grosse partition, celle de 29,5 GiB ? Avec la commande
resize2fs ? Si je peux la ramener, disons, à 7 GiB, l'image globale obtenue
avec dd n'atteindra pas 8 GiB.
Ma question devient : Puis-je redimensionner une partition d'un système
vivant depuis sa propre ligne de commande ?

Oui, c'est possible. Mais faire une opération aussi risquée pour te
prémunir contre une perte de données, c'est avoir les idées à l'envers.
Plutôt que de regrouper les données, on peut forcer le système à mettre
des zéros dans tout l'espace vide : créer un fichier ne contenant que
des zéros qui prend toute la place puis le supprimer. La compression
sera ensuite extrêmement efficace.
Mais le mieux est quand même d'abandonner l'idée d'utiliser une image.
Les images n'ont jamais été aussi utiles que leur réputation.
Geo Cherchetout
Le #26530759
Le 09/11/2019 21:59, *Nicolas George* a écrit :
Mais le mieux est quand même d'abandonner l'idée d'utiliser une image.
Les images n'ont jamais été aussi utiles que leur réputation.

Je comprends l'intérêt de tar et celui du fichier plein de zéros qu'on
efface mais je découvre à l'instant que j'ai déjà un outil de clonage
intelligent qui permet d'utiliser comme cible une carte de moindre capacité :
https://tech.scargill.net/raspberry-pi-backups/
Ça semble sans danger. J'essaye demain. Enfin, je veux dire aujourd'hui pour
ceux qui sont à l'heure de Paris...
Pascal Hambourg
Le #26530771
Le 09/11/2019 à 21:59, Nicolas George a écrit :
Geo Cherchetout , dans le message écrit :
Ce clone, réalisé alors que tout marche bien, servirait à restaurer système
et données en cas de défaillance de la carte SDHC actuelle.

Je m'en doutais. Pour l'essentiel du système, des fichiers tar sont un
bien meilleur choix.
La seule chose utile qu'une image embarque que des tarballs ne peuvent
pas embarquer, c'est le bootloader. Je ne sais pas comment marche le
bootloader sur ARM.

Sur le Raspberry Pi il y a une partition de boot en FAT, il me semble.
Etant donné sa petite taille, il est possible d'en faire une image.
Pour regrouper un peu les données, il est peut-être possible de
redimensionner la grosse partition, celle de 29,5 GiB ? Avec la commande
resize2fs ? Si je peux la ramener, disons, à 7 GiB, l'image globale obtenue
avec dd n'atteindra pas 8 GiB.
Ma question devient : Puis-je redimensionner une partition d'un système
vivant depuis sa propre ligne de commande ?

Oui, c'est possible.

Ça dépend du type de système de fichiers. La plupart des systèmes de
fichiers, incluant ext*, ne peuvent pas être réduits lorsqu'ils sont
montés, une exception notable étant btrfs.
Mais pourquoi vouloir le faire depuis le système lui-même alors qu'il
suffit de prendre la carte SD et la brancher sur une autre machine ? Tu
ne pourras (devras) pas non plus faire l'image lorsque la partition est
montée, le résultat risque d'être dans un état incohérent.
Plutôt que de regrouper les données, on peut forcer le système à mettre
des zéros dans tout l'espace vide : créer un fichier ne contenant que
des zéros qui prend toute la place puis le supprimer. La compression
sera ensuite extrêmement efficace.

Mais l'écriture use la carte SD.
Mais le mieux est quand même d'abandonner l'idée d'utiliser une image.

Ou bien faire une image "intelligente" qui ne contient que les données
utiles, comme peuvent le faire partclone, partimage ou clonezilla.
Geo Cherchetout
Le #26530885
Le 10/11/2019 09:05, *Pascal Hambourg* a écrit :
Ou bien faire une image "intelligente" qui ne contient que les données
utiles, comme peuvent le faire partclone, partimage ou clonezilla.

Avec raspbian buster, et peut-être aussi versions antérieures, un outil
spécial nommé piclone est fourni. J'ai donc voulu l'utiliser, et j'ai enfin
réussi après bien des tâtonnements. Merci à l'auteur de cet intelligent
programme. :-)
Je n'ai malheureusement pas trouvé de documentation quand à ce que fait au
juste piclone et comment il le fait. Ce qu'il faut deviner c'est qu'on doit
l'exécuter depuis une session graphique, lxde en l'occurence, alors que je
m'obstinais à le faire en ligne de commande. Pas besoin pour autant de
brancher un clavier et un écran comme j'étais sur le point de le faire en
désespoir de cause, j'ai tout fait via ssh.
Publicité
Poster une réponse
Anonyme