Le dimanche 31 janvier 2010, Aurelien a écrit :
> Visiblement, la copie a échoué. Malheureusement, je n'étais pas sur
> place, et je n'ai pas de log ou de messages d'erreur.
> Du coup, je suis bon pour recommencer ma propagation. J'ai maintenant 5
> machines installées sur 14. Qu'est-ce que vous me recommanderiez comme
> méthode de copie ? (parce que là, j'avoue que dd, pour moi, c'était le
> top, surtout via du firewire).
> Par ailleurs, cette histoire d'hdparm, est-ce que ça s'applique aux
> disques durs SATA, du coup ? (je suis pas super doué en UDMA, etc.)
> Aurélien
rsync ...
Le dimanche 31 janvier 2010, Aurelien a écrit :
> Visiblement, la copie a échoué. Malheureusement, je n'étais pas sur
> place, et je n'ai pas de log ou de messages d'erreur.
> Du coup, je suis bon pour recommencer ma propagation. J'ai maintenant 5
> machines installées sur 14. Qu'est-ce que vous me recommanderiez comme
> méthode de copie ? (parce que là, j'avoue que dd, pour moi, c'était le
> top, surtout via du firewire).
> Par ailleurs, cette histoire d'hdparm, est-ce que ça s'applique aux
> disques durs SATA, du coup ? (je suis pas super doué en UDMA, etc.)
> Aurélien
rsync ...
Le dimanche 31 janvier 2010, Aurelien a écrit :
> Visiblement, la copie a échoué. Malheureusement, je n'étais pas sur
> place, et je n'ai pas de log ou de messages d'erreur.
> Du coup, je suis bon pour recommencer ma propagation. J'ai maintenant 5
> machines installées sur 14. Qu'est-ce que vous me recommanderiez comme
> méthode de copie ? (parce que là, j'avoue que dd, pour moi, c'était le
> top, surtout via du firewire).
> Par ailleurs, cette histoire d'hdparm, est-ce que ça s'applique aux
> disques durs SATA, du coup ? (je suis pas super doué en UDMA, etc.)
> Aurélien
rsync ...
Salut,
Je suis en train de "propager" une install d'un Mac PPC sur d'autres Mac PPC, en
utilisant un PPC "source" et les autres comme des disques durs externes
(FireWire).
Je fais ça avec dd. Ca semble très lent (2.7Mb/s en moyenne).
Est-ce normal ?
Y a-t-il une option à passer ou un truc à faire pour aller plus vite (j'ai 14
machines à faire, et les disques font 150 Gb)
Salut,
Je suis en train de "propager" une install d'un Mac PPC sur d'autres Mac PPC, en
utilisant un PPC "source" et les autres comme des disques durs externes
(FireWire).
Je fais ça avec dd. Ca semble très lent (2.7Mb/s en moyenne).
Est-ce normal ?
Y a-t-il une option à passer ou un truc à faire pour aller plus vite (j'ai 14
machines à faire, et les disques font 150 Gb)
Salut,
Je suis en train de "propager" une install d'un Mac PPC sur d'autres Mac PPC, en
utilisant un PPC "source" et les autres comme des disques durs externes
(FireWire).
Je fais ça avec dd. Ca semble très lent (2.7Mb/s en moyenne).
Est-ce normal ?
Y a-t-il une option à passer ou un truc à faire pour aller plus vite (j'ai 14
machines à faire, et les disques font 150 Gb)
On Wed, Jan 27, 2010 at 08:05:20PM +0100, wrote:
> Salut,
>
> Je suis en train de "propager" une install d'un Mac PPC sur d'autres Mac PPC, en
> utilisant un PPC "source" et les autres comme des disques durs externes
> (FireWire).
>
> Je fais ça avec dd. Ca semble très lent (2.7Mb/s en moyenne).
>
> Est-ce normal ?
> Y a-t-il une option à passer ou un truc à faire pour aller plus vite (j'ai 14
> machines à faire, et les disques font 150 Gb)
Si le disque source n'est pas quasiment plein, ça sera bien plus rapide
de copier les données plutôt que tous les blocks à l'aveugle.
J'aurais deux pistes :
- regarder encore une fois partimage (j'avais eu des soucis de
compatibilité entre deux serveurs, mais là, tu est en local).
Regarder aussi si c'est pas plus simple d'utiliser clonezilla
- créer les partitions et filesystemes sur la cible, les monter et faire un
simple "cp -a", ou un "tar -c" pipé dans un "tar -x", ou encore un "cpio -p".
En cas d'erreur durant la copie, s'il faut la relancer, je le ferais
avec rsync pour ne pas perdre ce qui a déjà été copié.
On Wed, Jan 27, 2010 at 08:05:20PM +0100, tyranorl@free.fr wrote:
> Salut,
>
> Je suis en train de "propager" une install d'un Mac PPC sur d'autres Mac PPC, en
> utilisant un PPC "source" et les autres comme des disques durs externes
> (FireWire).
>
> Je fais ça avec dd. Ca semble très lent (2.7Mb/s en moyenne).
>
> Est-ce normal ?
> Y a-t-il une option à passer ou un truc à faire pour aller plus vite (j'ai 14
> machines à faire, et les disques font 150 Gb)
Si le disque source n'est pas quasiment plein, ça sera bien plus rapide
de copier les données plutôt que tous les blocks à l'aveugle.
J'aurais deux pistes :
- regarder encore une fois partimage (j'avais eu des soucis de
compatibilité entre deux serveurs, mais là, tu est en local).
Regarder aussi si c'est pas plus simple d'utiliser clonezilla
- créer les partitions et filesystemes sur la cible, les monter et faire un
simple "cp -a", ou un "tar -c" pipé dans un "tar -x", ou encore un "cpio -p".
En cas d'erreur durant la copie, s'il faut la relancer, je le ferais
avec rsync pour ne pas perdre ce qui a déjà été copié.
On Wed, Jan 27, 2010 at 08:05:20PM +0100, wrote:
> Salut,
>
> Je suis en train de "propager" une install d'un Mac PPC sur d'autres Mac PPC, en
> utilisant un PPC "source" et les autres comme des disques durs externes
> (FireWire).
>
> Je fais ça avec dd. Ca semble très lent (2.7Mb/s en moyenne).
>
> Est-ce normal ?
> Y a-t-il une option à passer ou un truc à faire pour aller plus vite (j'ai 14
> machines à faire, et les disques font 150 Gb)
Si le disque source n'est pas quasiment plein, ça sera bien plus rapide
de copier les données plutôt que tous les blocks à l'aveugle.
J'aurais deux pistes :
- regarder encore une fois partimage (j'avais eu des soucis de
compatibilité entre deux serveurs, mais là, tu est en local).
Regarder aussi si c'est pas plus simple d'utiliser clonezilla
- créer les partitions et filesystemes sur la cible, les monter et faire un
simple "cp -a", ou un "tar -c" pipé dans un "tar -x", ou encore un "cpio -p".
En cas d'erreur durant la copie, s'il faut la relancer, je le ferais
avec rsync pour ne pas perdre ce qui a déjà été copié.
J'ajoute un petit détail à mon problème, il est visiblement très peu
recommandé de toucher aux partitions HFS+ avec Linux, en particulier en
écriture. Du coup, j'imagine que monter les partitions HFS+ pour les
écrire n'est sans doute pas une super option.
Enfin, je peux faire une partie depuis Linux et les HFS+ depuis MAC OS
X, en fait.
J'ajoute un petit détail à mon problème, il est visiblement très peu
recommandé de toucher aux partitions HFS+ avec Linux, en particulier en
écriture. Du coup, j'imagine que monter les partitions HFS+ pour les
écrire n'est sans doute pas une super option.
Enfin, je peux faire une partie depuis Linux et les HFS+ depuis MAC OS
X, en fait.
J'ajoute un petit détail à mon problème, il est visiblement très peu
recommandé de toucher aux partitions HFS+ avec Linux, en particulier en
écriture. Du coup, j'imagine que monter les partitions HFS+ pour les
écrire n'est sans doute pas une super option.
Enfin, je peux faire une partie depuis Linux et les HFS+ depuis MAC OS
X, en fait.
On Sun, Jan 31, 2010 at 11:47:06AM +0100, Aurelien wrote:
[...]
> J'ajoute un petit détail à mon problème, il est visiblement très peu
> recommandé de toucher aux partitions HFS+ avec Linux, en particulier en
> écriture. Du coup, j'imagine que monter les partitions HFS+ pour les
> écrire n'est sans doute pas une super option.
> Enfin, je peux faire une partie depuis Linux et les HFS+ depuis MAC OS
> X, en fait.
Ah, j'avais pas vu le filesystem HFS+...
Le plus simple ne serait-il pas de faire tout ça sur un Mac, en effet ?
On Sun, Jan 31, 2010 at 11:47:06AM +0100, Aurelien wrote:
[...]
> J'ajoute un petit détail à mon problème, il est visiblement très peu
> recommandé de toucher aux partitions HFS+ avec Linux, en particulier en
> écriture. Du coup, j'imagine que monter les partitions HFS+ pour les
> écrire n'est sans doute pas une super option.
> Enfin, je peux faire une partie depuis Linux et les HFS+ depuis MAC OS
> X, en fait.
Ah, j'avais pas vu le filesystem HFS+...
Le plus simple ne serait-il pas de faire tout ça sur un Mac, en effet ?
On Sun, Jan 31, 2010 at 11:47:06AM +0100, Aurelien wrote:
[...]
> J'ajoute un petit détail à mon problème, il est visiblement très peu
> recommandé de toucher aux partitions HFS+ avec Linux, en particulier en
> écriture. Du coup, j'imagine que monter les partitions HFS+ pour les
> écrire n'est sans doute pas une super option.
> Enfin, je peux faire une partie depuis Linux et les HFS+ depuis MAC OS
> X, en fait.
Ah, j'avais pas vu le filesystem HFS+...
Le plus simple ne serait-il pas de faire tout ça sur un Mac, en effet ?
Pour vous préciser un peu l'histoire, les machines sources ont une table
de partitions (GPT) du type :
Pour vous préciser un peu l'histoire, les machines sources ont une table
de partitions (GPT) du type :
Pour vous préciser un peu l'histoire, les machines sources ont une table
de partitions (GPT) du type :
Je suis sur un Mac, avec une Debian Squeeze PPC installée dessus. L'id ée
est de propager cette install sur les 13 autres Mac (PPC, donc).
Aurélien
Je suis sur un Mac, avec une Debian Squeeze PPC installée dessus. L'id ée
est de propager cette install sur les 13 autres Mac (PPC, donc).
Aurélien
Je suis sur un Mac, avec une Debian Squeeze PPC installée dessus. L'id ée
est de propager cette install sur les 13 autres Mac (PPC, donc).
Aurélien
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 31/01/2010 06:08, Aurelien wrote:
[...]
> Pour vous préciser un peu l'histoire, les machines sources ont une table
> de partitions (GPT) du type :
Et les machines destination ont un disque strictement identique à la
machine source j'espère, sinon, GPT, qui écrit sa table de partition au
début *et* à la fin du disque risque de ne pas retrouver ses petits...
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 31/01/2010 06:08, Aurelien wrote:
[...]
> Pour vous préciser un peu l'histoire, les machines sources ont une table
> de partitions (GPT) du type :
Et les machines destination ont un disque strictement identique à la
machine source j'espère, sinon, GPT, qui écrit sa table de partition au
début *et* à la fin du disque risque de ne pas retrouver ses petits...
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 31/01/2010 06:08, Aurelien wrote:
[...]
> Pour vous préciser un peu l'histoire, les machines sources ont une table
> de partitions (GPT) du type :
Et les machines destination ont un disque strictement identique à la
machine source j'espère, sinon, GPT, qui écrit sa table de partition au
début *et* à la fin du disque risque de ne pas retrouver ses petits...
Le dimanche 31 janvier 2010, Aurelien a écrit :
> Je suis sur un Mac, avec une Debian Squeeze PPC installée dessus. L'idée
> est de propager cette install sur les 13 autres Mac (PPC, donc).
> Aurélien
"rsync" est très souple, avec moultes options.
Il peut donc garder tous les fichiers présents sur la cible
et ne rajouter que ceux qui viennent de la source.
On peut aussi avoir l'option inverse. (option --delete)
Dans un réseau, il fonctionne avec ssh (mode sécurisé) :
Exemple :
rsync -auvz --exclude=<répertoire> / <IP_cible>:<répertoire_cible>
Pour toutes ses options, voir man rsync,
J'ai mesuré avec bien des outils de sauvegarde :
10Go => ~20 minutes (entre 2 DD sur le même PC)
et ensuite c'est assez linéaire.
(un peu plus en mode réseau intranet et plus en internet ...)
Son grand avantage est que, en cas d'incident ou d'arrêt de copie,
il ne recommence pas à zéro, mais à l'endroit ou il s'est arrêté.
Ainsi, si on sauvegarde 1 Tera Octet (faut compter ~30 heures ...)
et que, 3 jours plus tard, on veut resauvegarder ce Téra octet, à peine modifié,
sur la même cible, rsync ne copiera exclusivement que la modification soit quelques minutes,
voire secondes.
Tu as rsync en mode graphique = LuckyBackup
Le dimanche 31 janvier 2010, Aurelien a écrit :
> Je suis sur un Mac, avec une Debian Squeeze PPC installée dessus. L'idée
> est de propager cette install sur les 13 autres Mac (PPC, donc).
> Aurélien
"rsync" est très souple, avec moultes options.
Il peut donc garder tous les fichiers présents sur la cible
et ne rajouter que ceux qui viennent de la source.
On peut aussi avoir l'option inverse. (option --delete)
Dans un réseau, il fonctionne avec ssh (mode sécurisé) :
Exemple :
rsync -auvz --exclude=<répertoire> / <IP_cible>:<répertoire_cible>
Pour toutes ses options, voir man rsync,
J'ai mesuré avec bien des outils de sauvegarde :
10Go => ~20 minutes (entre 2 DD sur le même PC)
et ensuite c'est assez linéaire.
(un peu plus en mode réseau intranet et plus en internet ...)
Son grand avantage est que, en cas d'incident ou d'arrêt de copie,
il ne recommence pas à zéro, mais à l'endroit ou il s'est arrêté.
Ainsi, si on sauvegarde 1 Tera Octet (faut compter ~30 heures ...)
et que, 3 jours plus tard, on veut resauvegarder ce Téra octet, à peine modifié,
sur la même cible, rsync ne copiera exclusivement que la modification soit quelques minutes,
voire secondes.
Tu as rsync en mode graphique = LuckyBackup
Le dimanche 31 janvier 2010, Aurelien a écrit :
> Je suis sur un Mac, avec une Debian Squeeze PPC installée dessus. L'idée
> est de propager cette install sur les 13 autres Mac (PPC, donc).
> Aurélien
"rsync" est très souple, avec moultes options.
Il peut donc garder tous les fichiers présents sur la cible
et ne rajouter que ceux qui viennent de la source.
On peut aussi avoir l'option inverse. (option --delete)
Dans un réseau, il fonctionne avec ssh (mode sécurisé) :
Exemple :
rsync -auvz --exclude=<répertoire> / <IP_cible>:<répertoire_cible>
Pour toutes ses options, voir man rsync,
J'ai mesuré avec bien des outils de sauvegarde :
10Go => ~20 minutes (entre 2 DD sur le même PC)
et ensuite c'est assez linéaire.
(un peu plus en mode réseau intranet et plus en internet ...)
Son grand avantage est que, en cas d'incident ou d'arrêt de copie,
il ne recommence pas à zéro, mais à l'endroit ou il s'est arrêté.
Ainsi, si on sauvegarde 1 Tera Octet (faut compter ~30 heures ...)
et que, 3 jours plus tard, on veut resauvegarder ce Téra octet, à peine modifié,
sur la même cible, rsync ne copiera exclusivement que la modification soit quelques minutes,
voire secondes.
Tu as rsync en mode graphique = LuckyBackup
On Thu, Jan 28, 2010 at 02:13:46PM +0100, Aurelien wrote :On Thu, Jan 28, 2010 at 11:09:00AM +0100, Yves Rutschle wrote :On Wed, Jan 27, 2010 at 11:02:45PM +0100, wrote:hdparm /dev/hd<x>
si using_dma = 0, alors:
hdparm -d 1 /dev/hd<x>
Sur les 2 disques, bien sûr.
OK. Je vais regarder de ce côté.
Oops, j'avais raté le faite que c'était du firewire -- du
coup, je ne sais pas si les histoires de DMA s'appliquent
(ça m'étonnerait).
Arf, dommage. Je vais regarder quand même. Il y a un deux disques qui
n'est pas en Firewire (mais en SATA, donc, bon, côté UDMA...)Je ne savais pas que je pouvais faire avec cp.
Si je fais cp -a /dev/sda /dev/sdb ça va marcher ? (j'ai besoin qu'il écrive la
table des partitions, etc.)
Attention, "cp -a /mnt/hda1 /mnt/hdb1"
^^^^ ^^^^
pas "dev"...
Il faut avoir déjà partitionné le disque, formaté les
partitions et monté les partitions là où il faut. Tout ça se
scripte facilement (avec sfdisk(8) pour le partitionnement).
Mouais. Je voulais pas trop aller dans ce sens là, car table de
partition type GPT (Mac), et du coup, pas assez sûr de moi là-dessus.
Salut,
Visiblement, la copie a échoué. Malheureusement, je n'étais pas sur
place, et je n'ai pas de log ou de messages d'erreur.
Du coup, je suis bon pour recommencer ma propagation. J'ai maintenant 5
machines installées sur 14. Qu'est-ce que vous me recommanderiez comme
méthode de copie ? (parce que là, j'avoue que dd, pour moi, c'était le
top, surtout via du firewire).
Par ailleurs, cette histoire d'hdparm, est-ce que ça s'applique aux
disques durs SATA, du coup ? (je suis pas super doué en UDMA, etc.)
Merci d'avance.
On Thu, Jan 28, 2010 at 02:13:46PM +0100, Aurelien wrote :
On Thu, Jan 28, 2010 at 11:09:00AM +0100, Yves Rutschle wrote :
On Wed, Jan 27, 2010 at 11:02:45PM +0100, tyranorl@free.fr wrote:
hdparm /dev/hd<x>
si using_dma = 0, alors:
hdparm -d 1 /dev/hd<x>
Sur les 2 disques, bien sûr.
OK. Je vais regarder de ce côté.
Oops, j'avais raté le faite que c'était du firewire -- du
coup, je ne sais pas si les histoires de DMA s'appliquent
(ça m'étonnerait).
Arf, dommage. Je vais regarder quand même. Il y a un deux disques qui
n'est pas en Firewire (mais en SATA, donc, bon, côté UDMA...)
Je ne savais pas que je pouvais faire avec cp.
Si je fais cp -a /dev/sda /dev/sdb ça va marcher ? (j'ai besoin qu'il écrive la
table des partitions, etc.)
Attention, "cp -a /mnt/hda1 /mnt/hdb1"
^^^^ ^^^^
pas "dev"...
Il faut avoir déjà partitionné le disque, formaté les
partitions et monté les partitions là où il faut. Tout ça se
scripte facilement (avec sfdisk(8) pour le partitionnement).
Mouais. Je voulais pas trop aller dans ce sens là, car table de
partition type GPT (Mac), et du coup, pas assez sûr de moi là-dessus.
Salut,
Visiblement, la copie a échoué. Malheureusement, je n'étais pas sur
place, et je n'ai pas de log ou de messages d'erreur.
Du coup, je suis bon pour recommencer ma propagation. J'ai maintenant 5
machines installées sur 14. Qu'est-ce que vous me recommanderiez comme
méthode de copie ? (parce que là, j'avoue que dd, pour moi, c'était le
top, surtout via du firewire).
Par ailleurs, cette histoire d'hdparm, est-ce que ça s'applique aux
disques durs SATA, du coup ? (je suis pas super doué en UDMA, etc.)
Merci d'avance.
On Thu, Jan 28, 2010 at 02:13:46PM +0100, Aurelien wrote :On Thu, Jan 28, 2010 at 11:09:00AM +0100, Yves Rutschle wrote :On Wed, Jan 27, 2010 at 11:02:45PM +0100, wrote:hdparm /dev/hd<x>
si using_dma = 0, alors:
hdparm -d 1 /dev/hd<x>
Sur les 2 disques, bien sûr.
OK. Je vais regarder de ce côté.
Oops, j'avais raté le faite que c'était du firewire -- du
coup, je ne sais pas si les histoires de DMA s'appliquent
(ça m'étonnerait).
Arf, dommage. Je vais regarder quand même. Il y a un deux disques qui
n'est pas en Firewire (mais en SATA, donc, bon, côté UDMA...)Je ne savais pas que je pouvais faire avec cp.
Si je fais cp -a /dev/sda /dev/sdb ça va marcher ? (j'ai besoin qu'il écrive la
table des partitions, etc.)
Attention, "cp -a /mnt/hda1 /mnt/hdb1"
^^^^ ^^^^
pas "dev"...
Il faut avoir déjà partitionné le disque, formaté les
partitions et monté les partitions là où il faut. Tout ça se
scripte facilement (avec sfdisk(8) pour le partitionnement).
Mouais. Je voulais pas trop aller dans ce sens là, car table de
partition type GPT (Mac), et du coup, pas assez sûr de moi là-dessus.
Salut,
Visiblement, la copie a échoué. Malheureusement, je n'étais pas sur
place, et je n'ai pas de log ou de messages d'erreur.
Du coup, je suis bon pour recommencer ma propagation. J'ai maintenant 5
machines installées sur 14. Qu'est-ce que vous me recommanderiez comme
méthode de copie ? (parce que là, j'avoue que dd, pour moi, c'était le
top, surtout via du firewire).
Par ailleurs, cette histoire d'hdparm, est-ce que ça s'applique aux
disques durs SATA, du coup ? (je suis pas super doué en UDMA, etc.)
Merci d'avance.