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 :
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...
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas George
Geo Cherchetout , dans le message <qq6sfp$2g9m$, a é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 , dans le message <qq6sfp$2g9m$1@news.gegeweb.eu>, a
é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 , dans le message <qq6sfp$2g9m$, a é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 09/11/2019 20:00, *Nicolas George* a écrit :
Geo Cherchetout , dans le message <qq6sfp$2g9m$, a é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 ?
Le 09/11/2019 20:00, *Nicolas George* a écrit :
Geo Cherchetout , dans le message <qq6sfp$2g9m$1@news.gegeweb.eu>, a
é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 ?
Geo Cherchetout , dans le message <qq6sfp$2g9m$, a é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
Geo Cherchetout , dans le message <qq78bb$2mn9$, a é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 , dans le message <qq78bb$2mn9$1@news.gegeweb.eu>, a
é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 , dans le message <qq78bb$2mn9$, a é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 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...
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...
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 09/11/2019 à 21:59, Nicolas George a écrit :
Geo Cherchetout , dans le message <qq78bb$2mn9$, a é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.
Le 09/11/2019 à 21:59, Nicolas George a écrit :
Geo Cherchetout , dans le message <qq78bb$2mn9$1@news.gegeweb.eu>, a
é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 , dans le message <qq78bb$2mn9$, a é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 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.
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.
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.
