bonjour,
je souhaiterai faire une copie de mon dd de 80go sur un autre
disque de la meme taille.
ils sont partionner exactement de la meme facon.
j ai "formater" mon disque B
dd if=/dev/zero of=/dev/ad2 count=2
et j ai essaye de copier la disque A vers le B
dd if=/dev/ad1 of=/dev/ad2
dd: /dev/ad1: Input/output error
209914+0 records in
209914+0 records out
107475968 bytes transferred in 65.549117 secs (1639625
bytes/sec)
dd if=/dev/ad1 of=/dev/null
dd: /dev/ad1: Input/output error
209914+0 records in
209914+0 records out
107475968 bytes transferred in 34.388560 secs (3125341
bytes/sec)
c est la premiere fois que j ai un message de ce type...
je me demande donc si il est trop tard pour faire un backup de
disque.
bonjour, je souhaiterai faire une copie de mon dd de 80go sur un autre disque de la meme taille. ils sont partionner exactement de la meme facon. j ai "formater" mon disque B
dd if=/dev/zero of=/dev/ad2 count=2
et j ai essaye de copier la disque A vers le B
dd if=/dev/ad1 of=/dev/ad2 dd: /dev/ad1: Input/output error 209914+0 records in 209914+0 records out 107475968 bytes transferred in 65.549117 secs (1639625 bytes/sec)
dd if=/dev/ad1 of=/dev/null dd: /dev/ad1: Input/output error 209914+0 records in 209914+0 records out 107475968 bytes transferred in 34.388560 secs (3125341 bytes/sec)
Il me semble que j'ai déjà vu ça. Sous FreeBSD le disklabel est protégé en écriture, si je me souviens bien, donc il doit être nécessaire de faire une invocation cabalistique avant de faire le dd.
c est la premiere fois que j ai un message de ce type... je me demande donc si il est trop tard pour faire un backup de disque.
merci d avance pour vos reponses et bon week-end.
-- Nico
-- Michel Talon
Nico <n.cormier@gmail.com> wrote:
bonjour,
je souhaiterai faire une copie de mon dd de 80go sur un autre
disque de la meme taille.
ils sont partionner exactement de la meme facon.
j ai "formater" mon disque B
dd if=/dev/zero of=/dev/ad2 count=2
et j ai essaye de copier la disque A vers le B
dd if=/dev/ad1 of=/dev/ad2
dd: /dev/ad1: Input/output error
209914+0 records in
209914+0 records out
107475968 bytes transferred in 65.549117 secs (1639625
bytes/sec)
dd if=/dev/ad1 of=/dev/null
dd: /dev/ad1: Input/output error
209914+0 records in
209914+0 records out
107475968 bytes transferred in 34.388560 secs (3125341
bytes/sec)
Il me semble que j'ai déjà vu ça. Sous FreeBSD le disklabel est
protégé en écriture, si je me souviens bien, donc il doit être
nécessaire de faire une invocation cabalistique avant de faire
le dd.
c est la premiere fois que j ai un message de ce type...
je me demande donc si il est trop tard pour faire un backup de
disque.
bonjour, je souhaiterai faire une copie de mon dd de 80go sur un autre disque de la meme taille. ils sont partionner exactement de la meme facon. j ai "formater" mon disque B
dd if=/dev/zero of=/dev/ad2 count=2
et j ai essaye de copier la disque A vers le B
dd if=/dev/ad1 of=/dev/ad2 dd: /dev/ad1: Input/output error 209914+0 records in 209914+0 records out 107475968 bytes transferred in 65.549117 secs (1639625 bytes/sec)
dd if=/dev/ad1 of=/dev/null dd: /dev/ad1: Input/output error 209914+0 records in 209914+0 records out 107475968 bytes transferred in 34.388560 secs (3125341 bytes/sec)
Il me semble que j'ai déjà vu ça. Sous FreeBSD le disklabel est protégé en écriture, si je me souviens bien, donc il doit être nécessaire de faire une invocation cabalistique avant de faire le dd.
c est la premiere fois que j ai un message de ce type... je me demande donc si il est trop tard pour faire un backup de disque.
merci d avance pour vos reponses et bon week-end.
-- Nico
-- Michel Talon
pornin
According to :
Il me semble que j'ai déjà vu ça. Sous FreeBSD le disklabel est protégé en écriture, si je me souviens bien, donc il doit être nécessaire de faire une invocation cabalistique avant de faire le dd.
C'est la commande disklabel, avec les flags -W et -N. cf le man.
Mais ce n'est probablement pas le problème ici : d'abord ça n'interdit que l'écriture, pas la lecture, et donc au moins la commande avec "of=/dev/null" devrait fonctionner. Ensuite, le disklabel est au début, pas après 100 Mo : ça devrait échouer immédiatement, pas après 30 ou 60 secondes. Enfin, l'erreur est EROFS, pas EIO, et donc ne devrait pas donner le message "I/O error" mais plutôt "read-only filesystem".
Plus probablement, le disque source a des secteurs défectueux, et c'est donc une très bonne idée de le changer.
Pour ce qui est de dupliquer une partition, on peut aussi faire ça avec dump et restore. Ça ne fait pas une copie fidèle bit-à-bit, mais c'est suffisant pour transférer un système, et ça s'accomode de quelques changements de tailles de partition ou d'options de filesystems. Il est possible que par ailleurs ça contourne le problème de secteur défectueux, si ledit secteur est actuellement dans une zone non attribuée.
--Thomas Pornin
According to <talon@lpthe.jussieu.fr>:
Il me semble que j'ai déjà vu ça. Sous FreeBSD le disklabel est
protégé en écriture, si je me souviens bien, donc il doit être
nécessaire de faire une invocation cabalistique avant de faire
le dd.
C'est la commande disklabel, avec les flags -W et -N. cf le man.
Mais ce n'est probablement pas le problème ici : d'abord ça n'interdit
que l'écriture, pas la lecture, et donc au moins la commande avec
"of=/dev/null" devrait fonctionner. Ensuite, le disklabel est au début,
pas après 100 Mo : ça devrait échouer immédiatement, pas après 30 ou 60
secondes. Enfin, l'erreur est EROFS, pas EIO, et donc ne devrait pas
donner le message "I/O error" mais plutôt "read-only filesystem".
Plus probablement, le disque source a des secteurs défectueux, et
c'est donc une très bonne idée de le changer.
Pour ce qui est de dupliquer une partition, on peut aussi faire ça avec
dump et restore. Ça ne fait pas une copie fidèle bit-à-bit, mais c'est
suffisant pour transférer un système, et ça s'accomode de quelques
changements de tailles de partition ou d'options de filesystems. Il
est possible que par ailleurs ça contourne le problème de secteur
défectueux, si ledit secteur est actuellement dans une zone non
attribuée.
Il me semble que j'ai déjà vu ça. Sous FreeBSD le disklabel est protégé en écriture, si je me souviens bien, donc il doit être nécessaire de faire une invocation cabalistique avant de faire le dd.
C'est la commande disklabel, avec les flags -W et -N. cf le man.
Mais ce n'est probablement pas le problème ici : d'abord ça n'interdit que l'écriture, pas la lecture, et donc au moins la commande avec "of=/dev/null" devrait fonctionner. Ensuite, le disklabel est au début, pas après 100 Mo : ça devrait échouer immédiatement, pas après 30 ou 60 secondes. Enfin, l'erreur est EROFS, pas EIO, et donc ne devrait pas donner le message "I/O error" mais plutôt "read-only filesystem".
Plus probablement, le disque source a des secteurs défectueux, et c'est donc une très bonne idée de le changer.
Pour ce qui est de dupliquer une partition, on peut aussi faire ça avec dump et restore. Ça ne fait pas une copie fidèle bit-à-bit, mais c'est suffisant pour transférer un système, et ça s'accomode de quelques changements de tailles de partition ou d'options de filesystems. Il est possible que par ailleurs ça contourne le problème de secteur défectueux, si ledit secteur est actuellement dans une zone non attribuée.
--Thomas Pornin
Jacques Caron
On 11 Sep 2004 02:05:45 -0700, Nico wrote:
j ai "formater" mon disque B
dd if=/dev/zero of=/dev/ad2 count=2
Pas vraiment nécessaire...
et j ai essaye de copier la disque A vers le B
dd if=/dev/ad1 of=/dev/ad2 dd: /dev/ad1: Input/output error 209914+0 records in 209914+0 records out 107475968 bytes transferred in 65.549117 secs (1639625 bytes/sec)
dd if=/dev/ad1 of=/dev/null dd: /dev/ad1: Input/output error 209914+0 records in 209914+0 records out 107475968 bytes transferred in 34.388560 secs (3125341 bytes/sec)
Que dit dmesg (ou /var/log/messages)?
je me demande donc si il est trop tard pour faire un backup de disque.
si c'est effectivement une erreur disque, c'est bien possible. Malheureusement, il y a théoriquement une option dans dd pour copier en "sautant" les bouts qui ne marchent pas mais en restant en phase (sync,noerror), mais ça ne marche pas sous FreeBSD. Je dois avoir quelque part un petit source qui fait la copie correctement dans ce cas de figure, si nécessaire.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
On 11 Sep 2004 02:05:45 -0700, Nico <n.cormier@gmail.com> wrote:
j ai "formater" mon disque B
dd if=/dev/zero of=/dev/ad2 count=2
Pas vraiment nécessaire...
et j ai essaye de copier la disque A vers le B
dd if=/dev/ad1 of=/dev/ad2
dd: /dev/ad1: Input/output error
209914+0 records in
209914+0 records out
107475968 bytes transferred in 65.549117 secs (1639625
bytes/sec)
dd if=/dev/ad1 of=/dev/null
dd: /dev/ad1: Input/output error
209914+0 records in
209914+0 records out
107475968 bytes transferred in 34.388560 secs (3125341
bytes/sec)
Que dit dmesg (ou /var/log/messages)?
je me demande donc si il est trop tard pour faire un backup de
disque.
si c'est effectivement une erreur disque, c'est bien possible.
Malheureusement, il y a théoriquement une option dans dd pour copier en
"sautant" les bouts qui ne marchent pas mais en restant en phase
(sync,noerror), mais ça ne marche pas sous FreeBSD. Je dois avoir quelque
part un petit source qui fait la copie correctement dans ce cas de figure,
si nécessaire.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
dd if=/dev/ad1 of=/dev/ad2 dd: /dev/ad1: Input/output error 209914+0 records in 209914+0 records out 107475968 bytes transferred in 65.549117 secs (1639625 bytes/sec)
dd if=/dev/ad1 of=/dev/null dd: /dev/ad1: Input/output error 209914+0 records in 209914+0 records out 107475968 bytes transferred in 34.388560 secs (3125341 bytes/sec)
Que dit dmesg (ou /var/log/messages)?
je me demande donc si il est trop tard pour faire un backup de disque.
si c'est effectivement une erreur disque, c'est bien possible. Malheureusement, il y a théoriquement une option dans dd pour copier en "sautant" les bouts qui ne marchent pas mais en restant en phase (sync,noerror), mais ça ne marche pas sous FreeBSD. Je dois avoir quelque part un petit source qui fait la copie correctement dans ce cas de figure, si nécessaire.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
n.cormier
(Thomas Pornin) wrote in message news:<chv6e9$3jd$...
Pour ce qui est de dupliquer une partition, on peut aussi faire ça avec dump et restore. Ça ne fait pas une copie fidèle bit-à-bit, mais c'est suffisant pour transférer un système, et ça s'accomode de quelques changements de tailles de partition ou d'options de filesystems. Il est possible que par ailleurs ça contourne le problème de secteur défectueux, si ledit secteur est actuellement dans une zone non attribuée.
ok je vais regarder de plus pres les mans ... merci ;)
pornin@nerim.net (Thomas Pornin) wrote in message news:<chv6e9$3jd$1@biggoron.nerim.net>...
Pour ce qui est de dupliquer une partition, on peut aussi faire ça avec
dump et restore. Ça ne fait pas une copie fidèle bit-à-bit, mais c'est
suffisant pour transférer un système, et ça s'accomode de quelques
changements de tailles de partition ou d'options de filesystems. Il
est possible que par ailleurs ça contourne le problème de secteur
défectueux, si ledit secteur est actuellement dans une zone non
attribuée.
ok je vais regarder de plus pres les mans ...
merci ;)
(Thomas Pornin) wrote in message news:<chv6e9$3jd$...
Pour ce qui est de dupliquer une partition, on peut aussi faire ça avec dump et restore. Ça ne fait pas une copie fidèle bit-à-bit, mais c'est suffisant pour transférer un système, et ça s'accomode de quelques changements de tailles de partition ou d'options de filesystems. Il est possible que par ailleurs ça contourne le problème de secteur défectueux, si ledit secteur est actuellement dans une zone non attribuée.
ok je vais regarder de plus pres les mans ... merci ;)
si c'est effectivement une erreur disque, c'est bien possible.
j en ai tt l impression...
Malheureusement, il y a théoriquement une option dans dd pour copier en "sautant" les bouts qui ne marchent pas mais en restant en phase (sync,noerror), mais ça ne marche pas sous FreeBSD. Je dois avoir quelque part un petit source qui fait la copie correctement dans ce cas de figure, si nécessaire.
merci bcp.
Jacques.
"Jacques Caron" <jc@imfeurope.com> wrote in message news:<opsd6ms2k8zscttn@news.free.fr>...
si c'est effectivement une erreur disque, c'est bien possible.
j en ai tt l impression...
Malheureusement, il y a théoriquement une option dans dd pour copier en
"sautant" les bouts qui ne marchent pas mais en restant en phase
(sync,noerror), mais ça ne marche pas sous FreeBSD. Je dois avoir quelque
part un petit source qui fait la copie correctement dans ce cas de figure,
si nécessaire.
si c'est effectivement une erreur disque, c'est bien possible.
j en ai tt l impression...
Malheureusement, il y a théoriquement une option dans dd pour copier en "sautant" les bouts qui ne marchent pas mais en restant en phase (sync,noerror), mais ça ne marche pas sous FreeBSD. Je dois avoir quelque part un petit source qui fait la copie correctement dans ce cas de figure, si nécessaire.
merci bcp.
Jacques.
n.cormier
(Thomas Pornin) wrote in message news:<chv6e9$3jd$...
According to :
Pour ce qui est de dupliquer une partition, on peut aussi faire ça avec dump et restore. Ça ne fait pas une copie fidèle bit-à-bit, mais c'est suffisant pour transférer un système, et ça s'accomode de quelques changements de tailles de partition ou d'options de filesystems. Il est possible que par ailleurs ça contourne le problème de secteur défectueux, si ledit secteur est actuellement dans une zone non attribuée.
juste une question: y a t il une grande difference entre dump-restore et un tar ?
pornin@nerim.net (Thomas Pornin) wrote in message news:<chv6e9$3jd$1@biggoron.nerim.net>...
According to <talon@lpthe.jussieu.fr>:
Pour ce qui est de dupliquer une partition, on peut aussi faire ça avec
dump et restore. Ça ne fait pas une copie fidèle bit-à-bit, mais c'est
suffisant pour transférer un système, et ça s'accomode de quelques
changements de tailles de partition ou d'options de filesystems. Il
est possible que par ailleurs ça contourne le problème de secteur
défectueux, si ledit secteur est actuellement dans une zone non
attribuée.
juste une question:
y a t il une grande difference entre dump-restore et un tar ?
(Thomas Pornin) wrote in message news:<chv6e9$3jd$...
According to :
Pour ce qui est de dupliquer une partition, on peut aussi faire ça avec dump et restore. Ça ne fait pas une copie fidèle bit-à-bit, mais c'est suffisant pour transférer un système, et ça s'accomode de quelques changements de tailles de partition ou d'options de filesystems. Il est possible que par ailleurs ça contourne le problème de secteur défectueux, si ledit secteur est actuellement dans une zone non attribuée.
juste une question: y a t il une grande difference entre dump-restore et un tar ?
pornin
According to Nico :
juste une question: y a t il une grande difference entre dump-restore et un tar ?
dump travaille directement sur le filesystem alors que tar accède aux fichiers et répertoire par leur nom. Ça permet à dump quelques optimisations. Notamment, dump gère correctement les "fichiers à trous" (un fichier Unix peut avoir des "trous", qui sont des zones vues comme remplies d'octets nuls, mais qui ne prennent pas de place sur le disque) alors que "tar" va recopier le trou comme une série de 0. Ça peut se voir en créant un fichier à trous :
$ dd if=/dev/zero ofºr bs=1 count=1 seek48576 1+0 records in 1+0 records out 1 bytes transferred in 0.000404 secs (2475 bytes/sec) $ tar cf foo.tar bar $ ls -ls bar foo.tar 48 -rw-r--r-- 1 pornin users 1048577 Sep 12 12:02 bar 1056 -rw-r--r-- 1 pornin users 1050624 Sep 12 12:02 foo.tar
La première commande crée un fichier "bar" commençant par un trou de 1 méga-octet suivi d'un unique octet de valeur 0. Vu de n'importe quel programme, le fichier "bar" est une suite de 1048577 octets de valeur 0. Par exemple, "tar" voit ce fichier ainsi, et crée une archive contenant ce fichier. L'archive elle-même fait 1050624 octets de long.
"ls -ls" montre en première colonne la taille réelle prise sur le disque par le fichier (incluant les divers blocs "administratifs" liés au fichier). On voit que "bar" est un fichier à trous : il ne prend que 48 kilo-octets sur le disque. En revanche, "foo.tar" prend ses 1056 kilo-octets au complet.
(Cet exemple a été fait sous FreeBSD-5.3-BETA1 du 21 août 2004, avec /usr/bin/tar, qui est un lien vers bsdtar. Ça marche aussi avec GNU tar.)
Ceci n'est qu'un exemple, mais ça montre que "dump" est mieux intégré dans le système que "tar". Le support de diverses autres fonctionnalités (comme les flags de fichiers, cf man chflags) sont également mieux supportés par "dump" que par "tar".
"dump" est un outil standard depuis pas mal de temps (plus de dix ans) et supporte diverses choses intéressantes, comme les sauvegardes incrémentales. Les versions récentes de certains "tar" (celui de GNU par exemple) peuvent aussi faire des choses intéressantes (notamment les sauvegardes incrémentales, à condition d'utiliser un fichier annexe pour stocker les informations afférentes), mais "dump" reste plus robuste pour du backup. Attention : je dis ça pour FreeBSD, et les *BSD en général. Ce n'est pas vrai sous Linux, où "dump" n'est conservé que pour des raisons historiques et est documenté comme sujet à diverses race-conditions qui le rendent non fiable.
En bref : on peut faire des choses avec "tar", et son format est standardisé, ce qui en fait un bon vecteur pour distribuer des données entre architectures. Mais pour des opérations assez bas niveau comme le backup ou la duplication de filesystems, "dump" est mieux.
--Thomas Pornin
According to Nico <n.cormier@gmail.com>:
juste une question:
y a t il une grande difference entre dump-restore et un tar ?
dump travaille directement sur le filesystem alors que tar accède
aux fichiers et répertoire par leur nom. Ça permet à dump quelques
optimisations. Notamment, dump gère correctement les "fichiers à trous"
(un fichier Unix peut avoir des "trous", qui sont des zones vues comme
remplies d'octets nuls, mais qui ne prennent pas de place sur le disque)
alors que "tar" va recopier le trou comme une série de 0. Ça peut se
voir en créant un fichier à trous :
$ dd if=/dev/zero ofºr bs=1 count=1 seek48576
1+0 records in
1+0 records out
1 bytes transferred in 0.000404 secs (2475 bytes/sec)
$ tar cf foo.tar bar
$ ls -ls bar foo.tar
48 -rw-r--r-- 1 pornin users 1048577 Sep 12 12:02 bar
1056 -rw-r--r-- 1 pornin users 1050624 Sep 12 12:02 foo.tar
La première commande crée un fichier "bar" commençant par un trou de 1
méga-octet suivi d'un unique octet de valeur 0. Vu de n'importe quel
programme, le fichier "bar" est une suite de 1048577 octets de valeur 0.
Par exemple, "tar" voit ce fichier ainsi, et crée une archive contenant
ce fichier. L'archive elle-même fait 1050624 octets de long.
"ls -ls" montre en première colonne la taille réelle prise sur le disque
par le fichier (incluant les divers blocs "administratifs" liés au
fichier). On voit que "bar" est un fichier à trous : il ne prend que
48 kilo-octets sur le disque. En revanche, "foo.tar" prend ses 1056
kilo-octets au complet.
(Cet exemple a été fait sous FreeBSD-5.3-BETA1 du 21 août 2004, avec
/usr/bin/tar, qui est un lien vers bsdtar. Ça marche aussi avec GNU
tar.)
Ceci n'est qu'un exemple, mais ça montre que "dump" est mieux intégré
dans le système que "tar". Le support de diverses autres fonctionnalités
(comme les flags de fichiers, cf man chflags) sont également mieux
supportés par "dump" que par "tar".
"dump" est un outil standard depuis pas mal de temps (plus de dix
ans) et supporte diverses choses intéressantes, comme les sauvegardes
incrémentales. Les versions récentes de certains "tar" (celui de GNU
par exemple) peuvent aussi faire des choses intéressantes (notamment
les sauvegardes incrémentales, à condition d'utiliser un fichier annexe
pour stocker les informations afférentes), mais "dump" reste plus
robuste pour du backup. Attention : je dis ça pour FreeBSD, et les *BSD
en général. Ce n'est pas vrai sous Linux, où "dump" n'est conservé que
pour des raisons historiques et est documenté comme sujet à diverses
race-conditions qui le rendent non fiable.
En bref : on peut faire des choses avec "tar", et son format est
standardisé, ce qui en fait un bon vecteur pour distribuer des données
entre architectures. Mais pour des opérations assez bas niveau comme le
backup ou la duplication de filesystems, "dump" est mieux.
juste une question: y a t il une grande difference entre dump-restore et un tar ?
dump travaille directement sur le filesystem alors que tar accède aux fichiers et répertoire par leur nom. Ça permet à dump quelques optimisations. Notamment, dump gère correctement les "fichiers à trous" (un fichier Unix peut avoir des "trous", qui sont des zones vues comme remplies d'octets nuls, mais qui ne prennent pas de place sur le disque) alors que "tar" va recopier le trou comme une série de 0. Ça peut se voir en créant un fichier à trous :
$ dd if=/dev/zero ofºr bs=1 count=1 seek48576 1+0 records in 1+0 records out 1 bytes transferred in 0.000404 secs (2475 bytes/sec) $ tar cf foo.tar bar $ ls -ls bar foo.tar 48 -rw-r--r-- 1 pornin users 1048577 Sep 12 12:02 bar 1056 -rw-r--r-- 1 pornin users 1050624 Sep 12 12:02 foo.tar
La première commande crée un fichier "bar" commençant par un trou de 1 méga-octet suivi d'un unique octet de valeur 0. Vu de n'importe quel programme, le fichier "bar" est une suite de 1048577 octets de valeur 0. Par exemple, "tar" voit ce fichier ainsi, et crée une archive contenant ce fichier. L'archive elle-même fait 1050624 octets de long.
"ls -ls" montre en première colonne la taille réelle prise sur le disque par le fichier (incluant les divers blocs "administratifs" liés au fichier). On voit que "bar" est un fichier à trous : il ne prend que 48 kilo-octets sur le disque. En revanche, "foo.tar" prend ses 1056 kilo-octets au complet.
(Cet exemple a été fait sous FreeBSD-5.3-BETA1 du 21 août 2004, avec /usr/bin/tar, qui est un lien vers bsdtar. Ça marche aussi avec GNU tar.)
Ceci n'est qu'un exemple, mais ça montre que "dump" est mieux intégré dans le système que "tar". Le support de diverses autres fonctionnalités (comme les flags de fichiers, cf man chflags) sont également mieux supportés par "dump" que par "tar".
"dump" est un outil standard depuis pas mal de temps (plus de dix ans) et supporte diverses choses intéressantes, comme les sauvegardes incrémentales. Les versions récentes de certains "tar" (celui de GNU par exemple) peuvent aussi faire des choses intéressantes (notamment les sauvegardes incrémentales, à condition d'utiliser un fichier annexe pour stocker les informations afférentes), mais "dump" reste plus robuste pour du backup. Attention : je dis ça pour FreeBSD, et les *BSD en général. Ce n'est pas vrai sous Linux, où "dump" n'est conservé que pour des raisons historiques et est documenté comme sujet à diverses race-conditions qui le rendent non fiable.
En bref : on peut faire des choses avec "tar", et son format est standardisé, ce qui en fait un bon vecteur pour distribuer des données entre architectures. Mais pour des opérations assez bas niveau comme le backup ou la duplication de filesystems, "dump" est mieux.
--Thomas Pornin
nicolas
On Sun, 12 Sep 2004 11:14:35 +0000, Thomas Pornin wrote:
$ dd if=/dev/zero ofºr bs=1 count=1 seek48576 1+0 records in 1+0 records out 1 bytes transferred in 0.000404 secs (2475 bytes/sec) $ tar cf foo.tar bar $ ls -ls bar foo.tar 48 -rw-r--r-- 1 pornin users 1048577 Sep 12 12:02 bar 1056 -rw-r--r-- 1 pornin users 1050624 Sep 12 12:02 foo.tar
En bref : on peut faire des choses avec "tar", et son format est standardisé, ce qui en fait un bon vecteur pour distribuer des données entre architectures. Mais pour des opérations assez bas niveau comme le backup ou la duplication de filesystems, "dump" est mieux.
--Thomas Pornin
merci pour cette reponse plus que complete... j ai effectue mon dump via ssh ca marche niquel. merci encore
-- Nicolas Cormier
On Sun, 12 Sep 2004 11:14:35 +0000, Thomas Pornin wrote:
$ dd if=/dev/zero ofºr bs=1 count=1 seek48576
1+0 records in
1+0 records out
1 bytes transferred in 0.000404 secs (2475 bytes/sec)
$ tar cf foo.tar bar
$ ls -ls bar foo.tar
48 -rw-r--r-- 1 pornin users 1048577 Sep 12 12:02 bar
1056 -rw-r--r-- 1 pornin users 1050624 Sep 12 12:02 foo.tar
En bref : on peut faire des choses avec "tar", et son format est
standardisé, ce qui en fait un bon vecteur pour distribuer des données
entre architectures. Mais pour des opérations assez bas niveau comme le
backup ou la duplication de filesystems, "dump" est mieux.
--Thomas Pornin
merci pour cette reponse plus que complete...
j ai effectue mon dump via ssh ca marche niquel. merci encore
On Sun, 12 Sep 2004 11:14:35 +0000, Thomas Pornin wrote:
$ dd if=/dev/zero ofºr bs=1 count=1 seek48576 1+0 records in 1+0 records out 1 bytes transferred in 0.000404 secs (2475 bytes/sec) $ tar cf foo.tar bar $ ls -ls bar foo.tar 48 -rw-r--r-- 1 pornin users 1048577 Sep 12 12:02 bar 1056 -rw-r--r-- 1 pornin users 1050624 Sep 12 12:02 foo.tar
En bref : on peut faire des choses avec "tar", et son format est standardisé, ce qui en fait un bon vecteur pour distribuer des données entre architectures. Mais pour des opérations assez bas niveau comme le backup ou la duplication de filesystems, "dump" est mieux.
--Thomas Pornin
merci pour cette reponse plus que complete... j ai effectue mon dump via ssh ca marche niquel. merci encore
-- Nicolas Cormier
nicolas
On Sun, 12 Sep 2004 17:12:55 +0200, Xavier wrote:
Thomas Pornin wrote:
dump impose en pratique un passage en single-user, ce qui pour la sauvegadre nocturne d'un serveur en prod, est difficilement faisable.
XAv
j ai vu que dump dispose de l option -L pour faire en live.
-- Nicolas Cormier
On Sun, 12 Sep 2004 17:12:55 +0200, Xavier wrote:
Thomas Pornin <pornin@nerim.net> wrote:
dump impose en pratique un passage en single-user, ce qui pour la
sauvegadre nocturne d'un serveur en prod, est difficilement faisable.
XAv
j ai vu que dump dispose de l option -L pour faire en live.
dump impose en pratique un passage en single-user, ce qui pour la sauvegadre nocturne d'un serveur en prod, est difficilement faisable.
XAv
j ai vu que dump dispose de l option -L pour faire en live.
-- Nicolas Cormier
talon
Xavier wrote:
nicolas wrote:
j ai vu que dump dispose de l option -L pour faire en live.
Mhû ? Ah, tiens oui, sur FreeBSD STABLE-5 (aka 5.3BETA), c'est exact. Par contre pour FreeBSD4, ni NetBSD, même en current (2.0G ici), ça n'existe pas.
Et ce n'est pourtant pas (comme tar, cpio) un hard link sur l'infâme pax.
Il s'agit de bsdtar, qui vient d'être écrit et n'a rien à voir avec pax.
Je vais send-PR-iser cela.
Sur FreeBSD-5 on peut faire des snapshots de filesystem et donc faire des dumps fiables sur un filesystem en fonctionnement.
Merci. -- Sondages au jour le jour Bush/Kerry http://www.groumpf.org/gwb/gwb-vs-Kerry.gif
-- Michel Talon
Xavier <xavier@groumpf.org> wrote:
nicolas <nico@rominet.home> wrote:
j ai vu que dump dispose de l option -L pour faire en live.
Mhû ? Ah, tiens oui, sur FreeBSD STABLE-5 (aka 5.3BETA), c'est exact.
Par contre pour FreeBSD4, ni NetBSD, même en current (2.0G ici), ça
n'existe pas.
Et ce n'est pourtant pas (comme tar, cpio) un hard link sur l'infâme
pax.
Il s'agit de bsdtar, qui vient d'être écrit et n'a rien à voir avec pax.
Je vais send-PR-iser cela.
Sur FreeBSD-5 on peut faire des snapshots de filesystem et donc faire
des dumps fiables sur un filesystem en fonctionnement.
Merci.
--
Sondages au jour le jour Bush/Kerry
http://www.groumpf.org/gwb/gwb-vs-Kerry.gif
j ai vu que dump dispose de l option -L pour faire en live.
Mhû ? Ah, tiens oui, sur FreeBSD STABLE-5 (aka 5.3BETA), c'est exact. Par contre pour FreeBSD4, ni NetBSD, même en current (2.0G ici), ça n'existe pas.
Et ce n'est pourtant pas (comme tar, cpio) un hard link sur l'infâme pax.
Il s'agit de bsdtar, qui vient d'être écrit et n'a rien à voir avec pax.
Je vais send-PR-iser cela.
Sur FreeBSD-5 on peut faire des snapshots de filesystem et donc faire des dumps fiables sur un filesystem en fonctionnement.
Merci. -- Sondages au jour le jour Bush/Kerry http://www.groumpf.org/gwb/gwb-vs-Kerry.gif
