Le 1 févr. 2012 à 18:03, Alain Vaugham a écrit :
> Le Wed, 01 Feb 2012 09:49:22 +0100,
> Carmelo a écrit :
>
> [...]
>> par contre j'ai 2 disques :
>>
>> un pour /
>> et un pour /home
>>
>> Je dois donc faire 2 fois la manip :
>>
>> # dd if =/dev/disqueRacine of /mnt/image_disqueRacine
>> # dd if =/dev/disqueHome of /mnt/image_disqueHome
>>
>> c'est bien ça ?
>
> Oui pour le premier dump car le MBR va venir avec
> le /mnt/image_disqueRacine.
> La restauration de l'image sera :
> # dd if=/cequetuveuxici/image_disqueRacine of=/dev/disqueécras é
pour le second disque /dev/sdc (qui est en fait mon dossier home), le
disque fait 160Go, mais seuls 10Go sont utilisés pour le moment.
comment faire avec 'dd' pour qu'il ne copie pas également l'espace
vide dans l'image ? que je me retrouve avec une image disque de 10
Go ?
j'ai regardé la doc de dd, mais je n'ai pas trouvé l'option pour
faire ça ...
Le 1 févr. 2012 à 18:03, Alain Vaugham a écrit :
> Le Wed, 01 Feb 2012 09:49:22 +0100,
> Carmelo <carmelo@ingrao.fr> a écrit :
>
> [...]
>> par contre j'ai 2 disques :
>>
>> un pour /
>> et un pour /home
>>
>> Je dois donc faire 2 fois la manip :
>>
>> # dd if =/dev/disqueRacine of /mnt/image_disqueRacine
>> # dd if =/dev/disqueHome of /mnt/image_disqueHome
>>
>> c'est bien ça ?
>
> Oui pour le premier dump car le MBR va venir avec
> le /mnt/image_disqueRacine.
> La restauration de l'image sera :
> # dd if=/cequetuveuxici/image_disqueRacine of=/dev/disqueécras é
pour le second disque /dev/sdc (qui est en fait mon dossier home), le
disque fait 160Go, mais seuls 10Go sont utilisés pour le moment.
comment faire avec 'dd' pour qu'il ne copie pas également l'espace
vide dans l'image ? que je me retrouve avec une image disque de 10
Go ?
j'ai regardé la doc de dd, mais je n'ai pas trouvé l'option pour
faire ça ...
Le 1 févr. 2012 à 18:03, Alain Vaugham a écrit :
> Le Wed, 01 Feb 2012 09:49:22 +0100,
> Carmelo a écrit :
>
> [...]
>> par contre j'ai 2 disques :
>>
>> un pour /
>> et un pour /home
>>
>> Je dois donc faire 2 fois la manip :
>>
>> # dd if =/dev/disqueRacine of /mnt/image_disqueRacine
>> # dd if =/dev/disqueHome of /mnt/image_disqueHome
>>
>> c'est bien ça ?
>
> Oui pour le premier dump car le MBR va venir avec
> le /mnt/image_disqueRacine.
> La restauration de l'image sera :
> # dd if=/cequetuveuxici/image_disqueRacine of=/dev/disqueécras é
pour le second disque /dev/sdc (qui est en fait mon dossier home), le
disque fait 160Go, mais seuls 10Go sont utilisés pour le moment.
comment faire avec 'dd' pour qu'il ne copie pas également l'espace
vide dans l'image ? que je me retrouve avec une image disque de 10
Go ?
j'ai regardé la doc de dd, mais je n'ai pas trouvé l'option pour
faire ça ...
Le Thu, 2 Feb 2012 16:10:55 +0100,
Alain Vaugham a écrit :
> Le Thu, 2 Feb 2012 09:08:07 +0100,
> Sébastien NOBILI a écrit :
>
> > Bonjour,
> >
> > Le mercredi 01 février 2012 à 18:03, Alain Vaugham a é crit :
> > > Un dernier point qu'il est peut-être inutile de préciser :
> > > l'image du /mnt/image_disqueRacine ne pourra être utilisé e que
> > > sur la machine d'origine à cause de
> > > la configuration des drivers.
> >
> > Contrairement à certains autres, le noyau Linux se transplante
> > très bien d'une machine à une autre. Sauf si l'architecture du
> > CPU est différente (ce qui a peu de chances d'être le cas), une
> > image d'un système installé sur une machine pourra fonction ner
> > sans problème sur une autre machine.
> >
>
> Je n'en doute pas mais dans le feu de l'action j'ai eu droit à une
> toute autre expérience malheureuse avec par exemple
> Machine source :
> - carte réseau 3Com
> - adaptateur graphique Nvidia
> - disque IDE
> Machine cible :
> - carte réseau Realtek
> - adaptateur graphique ATI
> - disque scsi
> Le reste à l'identique.
>
> Lors du reboot, la liste des erreurs restant a corriger manuellement
> est dissuasive pour un non expert comme moi. Elle est d'autant plus
> dissuasive que l'accident se produit toujours au moment où on a un
> besoin urgent de répondre à un mail pour une affaire importan te et
> que le serveur imap est en panne. Sans aller jusqu'Ã la
> transplantation du dump, le simple changement d'une carte réseau,
> donc changement de la macadress, va perturber le serveur DHCP qui
> attribue toujours la même ip fixe à la machine temporairement hors
> service.
>
> Bien sûr, tout cela se répare très bien ou pourrait à ªtre configuré
> différemment, mais replacé dans le contexte de la "sauvegarde d'un
> serveur debian", le swap avec un disque spare n'interrompt la
> disponibilité de la machine que quelques minutes. Dans mon cas, je
> n'ai qu'un étage à descendre pour avoir la main dessus.
>
> Cependant, je conçoit très bien que pouvoir transplanter un n oyau
> d'une machine à une autre est beaucoup plus enrichissant que
> débrancher/rebrancher un disque.
>
Je ne vois pas très bien ce que tu veux prouver. Le disque spare ne
serait pas plus efficace dans ce cas là ! Je te defies de brancher un
disque IDE sur une nappe SCSI !!
Expert ou pas, ton cas de figure est un vrai casse-tête dans les 2
cas.
Bruno
Le Thu, 2 Feb 2012 16:10:55 +0100,
Alain Vaugham <alain@vaugham.com> a écrit :
> Le Thu, 2 Feb 2012 09:08:07 +0100,
> Sébastien NOBILI <sebnewsletter@free.fr> a écrit :
>
> > Bonjour,
> >
> > Le mercredi 01 février 2012 à 18:03, Alain Vaugham a é crit :
> > > Un dernier point qu'il est peut-être inutile de préciser :
> > > l'image du /mnt/image_disqueRacine ne pourra être utilisé e que
> > > sur la machine d'origine à cause de
> > > la configuration des drivers.
> >
> > Contrairement à certains autres, le noyau Linux se transplante
> > très bien d'une machine à une autre. Sauf si l'architecture du
> > CPU est différente (ce qui a peu de chances d'être le cas), une
> > image d'un système installé sur une machine pourra fonction ner
> > sans problème sur une autre machine.
> >
>
> Je n'en doute pas mais dans le feu de l'action j'ai eu droit à une
> toute autre expérience malheureuse avec par exemple
> Machine source :
> - carte réseau 3Com
> - adaptateur graphique Nvidia
> - disque IDE
> Machine cible :
> - carte réseau Realtek
> - adaptateur graphique ATI
> - disque scsi
> Le reste à l'identique.
>
> Lors du reboot, la liste des erreurs restant a corriger manuellement
> est dissuasive pour un non expert comme moi. Elle est d'autant plus
> dissuasive que l'accident se produit toujours au moment où on a un
> besoin urgent de répondre à un mail pour une affaire importan te et
> que le serveur imap est en panne. Sans aller jusqu'Ã la
> transplantation du dump, le simple changement d'une carte réseau,
> donc changement de la macadress, va perturber le serveur DHCP qui
> attribue toujours la même ip fixe à la machine temporairement hors
> service.
>
> Bien sûr, tout cela se répare très bien ou pourrait à ªtre configuré
> différemment, mais replacé dans le contexte de la "sauvegarde d'un
> serveur debian", le swap avec un disque spare n'interrompt la
> disponibilité de la machine que quelques minutes. Dans mon cas, je
> n'ai qu'un étage à descendre pour avoir la main dessus.
>
> Cependant, je conçoit très bien que pouvoir transplanter un n oyau
> d'une machine à une autre est beaucoup plus enrichissant que
> débrancher/rebrancher un disque.
>
Je ne vois pas très bien ce que tu veux prouver. Le disque spare ne
serait pas plus efficace dans ce cas là ! Je te defies de brancher un
disque IDE sur une nappe SCSI !!
Expert ou pas, ton cas de figure est un vrai casse-tête dans les 2
cas.
Bruno
Le Thu, 2 Feb 2012 16:10:55 +0100,
Alain Vaugham a écrit :
> Le Thu, 2 Feb 2012 09:08:07 +0100,
> Sébastien NOBILI a écrit :
>
> > Bonjour,
> >
> > Le mercredi 01 février 2012 à 18:03, Alain Vaugham a é crit :
> > > Un dernier point qu'il est peut-être inutile de préciser :
> > > l'image du /mnt/image_disqueRacine ne pourra être utilisé e que
> > > sur la machine d'origine à cause de
> > > la configuration des drivers.
> >
> > Contrairement à certains autres, le noyau Linux se transplante
> > très bien d'une machine à une autre. Sauf si l'architecture du
> > CPU est différente (ce qui a peu de chances d'être le cas), une
> > image d'un système installé sur une machine pourra fonction ner
> > sans problème sur une autre machine.
> >
>
> Je n'en doute pas mais dans le feu de l'action j'ai eu droit à une
> toute autre expérience malheureuse avec par exemple
> Machine source :
> - carte réseau 3Com
> - adaptateur graphique Nvidia
> - disque IDE
> Machine cible :
> - carte réseau Realtek
> - adaptateur graphique ATI
> - disque scsi
> Le reste à l'identique.
>
> Lors du reboot, la liste des erreurs restant a corriger manuellement
> est dissuasive pour un non expert comme moi. Elle est d'autant plus
> dissuasive que l'accident se produit toujours au moment où on a un
> besoin urgent de répondre à un mail pour une affaire importan te et
> que le serveur imap est en panne. Sans aller jusqu'Ã la
> transplantation du dump, le simple changement d'une carte réseau,
> donc changement de la macadress, va perturber le serveur DHCP qui
> attribue toujours la même ip fixe à la machine temporairement hors
> service.
>
> Bien sûr, tout cela se répare très bien ou pourrait à ªtre configuré
> différemment, mais replacé dans le contexte de la "sauvegarde d'un
> serveur debian", le swap avec un disque spare n'interrompt la
> disponibilité de la machine que quelques minutes. Dans mon cas, je
> n'ai qu'un étage à descendre pour avoir la main dessus.
>
> Cependant, je conçoit très bien que pouvoir transplanter un n oyau
> d'une machine à une autre est beaucoup plus enrichissant que
> débrancher/rebrancher un disque.
>
Je ne vois pas très bien ce que tu veux prouver. Le disque spare ne
serait pas plus efficace dans ce cas là ! Je te defies de brancher un
disque IDE sur une nappe SCSI !!
Expert ou pas, ton cas de figure est un vrai casse-tête dans les 2
cas.
Bruno
[â¦]
> comment faire avec 'dd' pour qu'il ne copie pas également
> l'espace vide dans l'image ? que je me retrouve avec une
> image disque de 10 Go ?
[â¦]
> j'ai regardé la doc de dd, mais je n'ai pas trouvé l'option
> pour faire ça ...
Je ne sais pas si cette formule peut le faire :
dd if=inputfile of=outputfile bs24k count=1
Elle ne prend que les premiers 1024k.
Ca marche bien pour un fichier son. Peut-être qu'il faudrait
tester pour voir si une partition accepterai d'être tronquée
sur sa fin en essayant différentes valeurs. Un expert qui
passerai par ici nous expliquera que c'est peut-être
inutilisable. Si j'avais le temps je tenterai le coup.
[â¦]
> comment faire avec 'dd' pour qu'il ne copie pas également
> l'espace vide dans l'image ? que je me retrouve avec une
> image disque de 10 Go ?
[â¦]
> j'ai regardé la doc de dd, mais je n'ai pas trouvé l'option
> pour faire ça ...
Je ne sais pas si cette formule peut le faire :
dd if=inputfile of=outputfile bs=1024k count=1
Elle ne prend que les premiers 1024k.
Ca marche bien pour un fichier son. Peut-être qu'il faudrait
tester pour voir si une partition accepterai d'être tronquée
sur sa fin en essayant différentes valeurs. Un expert qui
passerai par ici nous expliquera que c'est peut-être
inutilisable. Si j'avais le temps je tenterai le coup.
[â¦]
> comment faire avec 'dd' pour qu'il ne copie pas également
> l'espace vide dans l'image ? que je me retrouve avec une
> image disque de 10 Go ?
[â¦]
> j'ai regardé la doc de dd, mais je n'ai pas trouvé l'option
> pour faire ça ...
Je ne sais pas si cette formule peut le faire :
dd if=inputfile of=outputfile bs24k count=1
Elle ne prend que les premiers 1024k.
Ca marche bien pour un fichier son. Peut-être qu'il faudrait
tester pour voir si une partition accepterai d'être tronquée
sur sa fin en essayant différentes valeurs. Un expert qui
passerai par ici nous expliquera que c'est peut-être
inutilisable. Si j'avais le temps je tenterai le coup.
dd ne sait pas (et nâa pas à savoir) ce quâil y a dans les
fichiers¹ quâil manipule. Il copie les octets (par blocs de
taille bs), autant quâon lui demande (count), en en sautant
autant quâon lui demande (skip). Il ne sait pas (et nâa p as Ã
savoir) si, dedans, il y a un système de fichiers et que tel ou
tel octet est utile ou nâest que de lâespace inutilisà ©.
2. Et non, Jean-Yves, il nây a pas besoin dâavoir rempli sa
partoche de zéros avant son utilisation pour que partimage
puisse ne sâintéresser quâaux données utilesâ ¦
dd ne sait pas (et nâa pas à savoir) ce quâil y a dans les
fichiers¹ quâil manipule. Il copie les octets (par blocs de
taille bs), autant quâon lui demande (count), en en sautant
autant quâon lui demande (skip). Il ne sait pas (et nâa p as Ã
savoir) si, dedans, il y a un système de fichiers et que tel ou
tel octet est utile ou nâest que de lâespace inutilisà ©.
2. Et non, Jean-Yves, il nây a pas besoin dâavoir rempli sa
partoche de zéros avant son utilisation pour que partimage
puisse ne sâintéresser quâaux données utilesâ ¦
dd ne sait pas (et nâa pas à savoir) ce quâil y a dans les
fichiers¹ quâil manipule. Il copie les octets (par blocs de
taille bs), autant quâon lui demande (count), en en sautant
autant quâon lui demande (skip). Il ne sait pas (et nâa p as Ã
savoir) si, dedans, il y a un système de fichiers et que tel ou
tel octet est utile ou nâest que de lâespace inutilisà ©.
2. Et non, Jean-Yves, il nây a pas besoin dâavoir rempli sa
partoche de zéros avant son utilisation pour que partimage
puisse ne sâintéresser quâaux données utilesâ ¦
Bonjour,
Le mercredi 01 février 2012 à 18:03, Alain Vaugham a écrit :Un dernier point qu'il est peut-être inutile de préciser : l'image
du /mnt/image_disqueRacine ne pourra être utilisée que sur la machin e
d'origine à cause de
la configuration des drivers.
Contrairement à certains autres, le noyau Linux se transplante très b ien
d'une
machine à une autre. Sauf si l'architecture du CPU est différente (ce qui a
peu
de chances d'être le cas), une image d'un système installé sur une machine
pourra fonctionner sans problème sur une autre machine.
Seb
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive:
http://lists.debian.org/
Bonjour,
Le mercredi 01 février 2012 à 18:03, Alain Vaugham a écrit :
Un dernier point qu'il est peut-être inutile de préciser : l'image
du /mnt/image_disqueRacine ne pourra être utilisée que sur la machin e
d'origine à cause de
la configuration des drivers.
Contrairement à certains autres, le noyau Linux se transplante très b ien
d'une
machine à une autre. Sauf si l'architecture du CPU est différente (ce qui a
peu
de chances d'être le cas), une image d'un système installé sur une machine
pourra fonctionner sans problème sur une autre machine.
Seb
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive:
http://lists.debian.org/20120202080807.GA8407@sebian.nob900.homeip.net
Bonjour,
Le mercredi 01 février 2012 à 18:03, Alain Vaugham a écrit :Un dernier point qu'il est peut-être inutile de préciser : l'image
du /mnt/image_disqueRacine ne pourra être utilisée que sur la machin e
d'origine à cause de
la configuration des drivers.
Contrairement à certains autres, le noyau Linux se transplante très b ien
d'une
machine à une autre. Sauf si l'architecture du CPU est différente (ce qui a
peu
de chances d'être le cas), une image d'un système installé sur une machine
pourra fonctionner sans problème sur une autre machine.
Seb
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive:
http://lists.debian.org/
Je n'ai aucune expérience personnelle sur le sujet mais j'aurai plus
pensé le contraire (qu'une image créée sur une machine ne pouvait pas
être copiée sur une autre (et que celle-ci fonctionne correctem ent
évidemment)).
Que se passe-t-il, par exemple, en cas de carte réseau différen te ?
Il est vraisemblable que l'interface change de nom ce qui peut perdre
certains daemons (comme le serveur DHCP).
Je n'ai aucune expérience personnelle sur le sujet mais j'aurai plus
pensé le contraire (qu'une image créée sur une machine ne pouvait pas
être copiée sur une autre (et que celle-ci fonctionne correctem ent
évidemment)).
Que se passe-t-il, par exemple, en cas de carte réseau différen te ?
Il est vraisemblable que l'interface change de nom ce qui peut perdre
certains daemons (comme le serveur DHCP).
Je n'ai aucune expérience personnelle sur le sujet mais j'aurai plus
pensé le contraire (qu'une image créée sur une machine ne pouvait pas
être copiée sur une autre (et que celle-ci fonctionne correctem ent
évidemment)).
Que se passe-t-il, par exemple, en cas de carte réseau différen te ?
Il est vraisemblable que l'interface change de nom ce qui peut perdre
certains daemons (comme le serveur DHCP).
On Wed, 8 Feb 2012 11:32:25 +0100
Olivier wrote:Je n'ai aucune expérience personnelle sur le sujet mais j'aurai plu s
pensé le contraire (qu'une image créée sur une machine ne pouvait pas
être copiée sur une autre (et que celle-ci fonctionne correcte ment
évidemment)).
Linux â w$, du moment que l'architecture est la même, ç a marche.
Que se passe-t-il, par exemple, en cas de carte réseau différe nte ?
Tout dépend du kernel utilisé; si c'est une compilation perso i l
faut bien évidemment prévoir les différentes Ctes, si c'es t du
Debian il n'y-a normalement aucun PB lors de la migration.Il est vraisemblable que l'interface change de nom ce qui peut perdre
certains daemons (comme le serveur DHCP).
Il n'a pas dit non plus qu'il suffisait de copier et que ça roulait
sans modif(s); le passage d'eth0 en eth1 Ã cause du changement de
MAC est largement documenté sur le web et dans cette ML.
On Wed, 8 Feb 2012 11:32:25 +0100
Olivier <oza_4h07@yahoo.fr> wrote:
Je n'ai aucune expérience personnelle sur le sujet mais j'aurai plu s
pensé le contraire (qu'une image créée sur une machine ne pouvait pas
être copiée sur une autre (et que celle-ci fonctionne correcte ment
évidemment)).
Linux â w$, du moment que l'architecture est la même, ç a marche.
Que se passe-t-il, par exemple, en cas de carte réseau différe nte ?
Tout dépend du kernel utilisé; si c'est une compilation perso i l
faut bien évidemment prévoir les différentes Ctes, si c'es t du
Debian il n'y-a normalement aucun PB lors de la migration.
Il est vraisemblable que l'interface change de nom ce qui peut perdre
certains daemons (comme le serveur DHCP).
Il n'a pas dit non plus qu'il suffisait de copier et que ça roulait
sans modif(s); le passage d'eth0 en eth1 Ã cause du changement de
MAC est largement documenté sur le web et dans cette ML.
On Wed, 8 Feb 2012 11:32:25 +0100
Olivier wrote:Je n'ai aucune expérience personnelle sur le sujet mais j'aurai plu s
pensé le contraire (qu'une image créée sur une machine ne pouvait pas
être copiée sur une autre (et que celle-ci fonctionne correcte ment
évidemment)).
Linux â w$, du moment que l'architecture est la même, ç a marche.
Que se passe-t-il, par exemple, en cas de carte réseau différe nte ?
Tout dépend du kernel utilisé; si c'est une compilation perso i l
faut bien évidemment prévoir les différentes Ctes, si c'es t du
Debian il n'y-a normalement aucun PB lors de la migration.Il est vraisemblable que l'interface change de nom ce qui peut perdre
certains daemons (comme le serveur DHCP).
Il n'a pas dit non plus qu'il suffisait de copier et que ça roulait
sans modif(s); le passage d'eth0 en eth1 Ã cause du changement de
MAC est largement documenté sur le web et dans cette ML.
Architecture en sens d'une machine i386, ia64 vers une autre, c'est à §a ?
Si c'est ça, alors c'est vraiment une propriété très intéressante de Linux !
Architecture en sens d'une machine i386, ia64 vers une autre, c'est à §a ?
Si c'est ça, alors c'est vraiment une propriété très intéressante de Linux !
Architecture en sens d'une machine i386, ia64 vers une autre, c'est à §a ?
Si c'est ça, alors c'est vraiment une propriété très intéressante de Linux !