Problème restauration sauvegarde avec tar

Le Fri, 03 Oct 2003 00:55:12 +0200, dominique becaert a ecrit:
| Bonjour,
|
Salut,

| J'ai un problème de restauration de sauvegarde, sur mon antique
| portable.
| C'est un 486dx75, sans lecteur de CD, mais avec carte réseau pcmcia.
| Le HD fait 810 Mo, et j'ai fait la sauvegarde en bootant avec une
| Tomsrtbt et en utilisant Netcat (nc).
|
| Commandes lancées pour la constitution de la sauvegarde :
| Sur le serveur de stockage :
| $ nc -l -p 1234 > fichier.tgz
| Sur le portable :
| $ tar cvf - /mnt | gzip | nc 192.168.0.6 1234
|
| Ce fut long, mais je ne me rappelle pas avoir eu de messages d'erreur.
|
| Je viens d'essayer de restaurer la sauvegarde.
| Sur le portable :
| $ nc -l -p 1234 | tar xvf -

A quel endroit fais tu ca? Sur /mnt, non? Les partitions (si partition
il y a) sont bien au on endroit egalement?

| Sur le serveur :
| $ zcat fichier.tgz | nc -v -w 5 192.168.0.7 1234
|
le w sert a quoi? (j'ai lu le man, mais je ne comprends pas bien son
utilite la)

| Cela démarre très bien, mais en arrivant sur un gros fichier (je ne sais
| pas si c'est une coïncidence), ça coince d'abord sur le portable :
| x /mnt/usr/lib/libc.a 20019674 bytes, 39101 tape blocks
| tar: -: This doesn't look like a tar archive
| tar: -: Skipping to next file
|
| J'ai un temps douté de mes commandes, et puis j'ai testé l'archive
| directement sur le serveur :
| $ tar tzvf fichier.tgz
| [snip]
| -rw-r--r-- root/root 20019674 1999-09-16 02:34 /mnt/usr/lib/libc.a
| tar: Skipping to next file header
| incomplete literal tree
| gzip: stdin: invalid compressed data--format violated
| tar: Child returned status 1
| tar: Error exit delayed from previous errors
|
et les autres fichiers? S'il ne s'agit que de celui-ci, il y a
toujours moyen d'aller le repecher sur le site de slackware.

| Alors je me demande s'il s'agit d'une limitation de tar ou de gzip sur
| la Tomsrtbt, qui m'aurait créé une archive incorrecte ... Est-ce que
| quelqu'un aurait déjà rencontré un problème similaire ?
|
| En écrivant ces lignes, je repense au fait que le portable n'a pas
| énormément de ram. Il en a maintenant 32 Mo, mais n'en avait que 24
| quand j'ai fait la sauvegarde. Et la Tomsrtbt se charge justement en
| ram, ce qui limite encore. Pourtant, il me semble bien que j'avais
| activé l'utilisation de la partition de swap (64 Mo), avec un
| $ swapon /dev/hda1
| ... Mais est-ce que lancer un gzip sur un fichier plus grand que la ram
| disponible, ça ne peut pas poser problème ?
|
A vue de nez, je dirais non. Le systeme utilise la RAM+swap comme s'il
s'agissait de RAM uniquement. Ca devrait etre transparent.

| Merci d'avance !

Si ca marche, je referais un test de sauvegarde, et j'essaierais
de retester tout ca sur le serveur. Eventuellement avec moins de RAM,
par exemple, au boot de la toms, un
linux mem=8M
pour voir si la sauvegarde se fait bien, tout ca.

--
Kevin
C'est vraaaaaiment etrange.
-+- Les 100 choses que vous n'aimez pas entendre de la part du sysadmin -+-

| Je viens d'essayer de restaurer la sauvegarde.
| Sur le portable :
| $ nc -l -p 1234 | tar xvf -

A quel endroit fais tu ca? Sur /mnt, non? Les partitions (si partition
il y a) sont bien au on endroit egalement?

Je monte la partition sur /mnt et je me place à la racine :
$ mount /dev/hda2 /mnt
$ cd /

| Sur le serveur :
| $ zcat fichier.tgz | nc -v -w 5 192.168.0.7 1234
|
le w sert a quoi? (j'ai lu le man, mais je ne comprends pas bien son
utilite la)

J'ai fait un essai avant, avec un tout petit tgz, pour voir si ça
décompressait bien au bon endroit :-)
Et je me suis aperçu que je ne récupérais la main qu'en faisant un
Ctrl-C.
Avec le tout petit tgz d'essai, pas de problème. Mais avec un tgz de 200
Mo, pas évident de savoir si c'est terminé, ou encore en train de
décompresser. J'ai donc mis le time out côté serveur (l'option -w
n'existe pas avec le nc light de la Tomsrtbt), et je récupère bien la
main.

| $ tar tzvf fichier.tgz
| [snip]
| -rw-r--r-- root/root 20019674 1999-09-16 02:34 /mnt/usr/lib/libc.a
| tar: Skipping to next file header
| incomplete literal tree
| gzip: stdin: invalid compressed data--format violated
| tar: Child returned status 1
| tar: Error exit delayed from previous errors
|
et les autres fichiers? S'il ne s'agit que de celui-ci, il y a
toujours moyen d'aller le repecher sur le site de slackware.

Le problème, c'est que justement ça s'arrête là.
Aussi bien lors de l'extraction que lors du test de l'archive avec
$ tar tzvf fichier.tgz

Si ca marche, je referais un test de sauvegarde, et j'essaierais
de retester tout ca sur le serveur. Eventuellement avec moins de RAM,
par exemple, au boot de la toms, un
linux mem=8M
pour voir si la sauvegarde se fait bien, tout ca.

Je vais refaire une sauvegarde. D'abord pour en avoir une valide (!). Et
puis pour voir si ça reproduit l'erreur.
Après tout, il s'agit peut-être simplement d'un problème sur le disque
du serveur ?
--
"S'il n'y a pas de solution,
c'est qu'il n'y a pas de problème"
Proverbe Shadok

Si ca marche, je referais un test de sauvegarde, et j'essaierais
de retester tout ca sur le serveur. Eventuellement avec moins de RAM,
par exemple, au boot de la toms, un
linux mem=8M
pour voir si la sauvegarde se fait bien, tout ca.

En fait, ma restauration de sauvegarde c'était pour transférer une image
de la slack de ma machine vers le HD d'un copain, qui a récupéré
exactement le même portable Compaq 486dx75 LTE.
C'est plus simple et plus rapide que de se taper une installation +
configuration, depuis un lecteur Zip sur port parallèle.

J'ai contourné le problème en refaisant une sauvegarde complète de mon
HD en faisant un simple tar, sans compression.
Et j'ai restauré l'image sur l'autre HD, il n'y a eu aucun problème.
Je vais compresser le tar sur mon serveur, histoire de gagner de la
place.
Mais je vais recommencer une sauvegarde avec compression à la volée, ce
n'est pas normal que ça foire. C'est peut-être le gzip de la Tomsrtbt
qui a un souci ...

PS: pour sk.pl et swen, j'ai été pas mal occupé, mais je m'y remets ce
week-end.
--
"S'il n'y a pas de solution,
c'est qu'il n'y a pas de problème"
Proverbe Shadok

Le Fri, 03 Oct 2003 12:12:03 +0200, dominique becaert a ecrit:
|
|> Si ca marche, je referais un test de sauvegarde, et j'essaierais
|> de retester tout ca sur le serveur. Eventuellement avec moins de RAM,
|> par exemple, au boot de la toms, un
|> linux mem=8M
|> pour voir si la sauvegarde se fait bien, tout ca.
|
| En fait, ma restauration de sauvegarde c'était pour transférer une image
| de la slack de ma machine vers le HD d'un copain, qui a récupéré
| exactement le même portable Compaq 486dx75 LTE.

ah bah tiens, je vais me mettre a l'installation d'une zipslack
la-dessus. la 9.1 me parait bien.

| C'est plus simple et plus rapide que de se taper une installation +
| configuration, depuis un lecteur Zip sur port parallèle.
|
| J'ai contourné le problème en refaisant une sauvegarde complète de mon
| HD en faisant un simple tar, sans compression.
| Et j'ai restauré l'image sur l'autre HD, il n'y a eu aucun problème.
| Je vais compresser le tar sur mon serveur, histoire de gagner de la
| place.
| Mais je vais recommencer une sauvegarde avec compression à la volée, ce
| n'est pas normal que ça foire. C'est peut-être le gzip de la Tomsrtbt
| qui a un souci ...
|
ca me surprendrait, quand meme (?)
un cluster defectueux sur le serveur qui aurait plante?

| PS: pour sk.pl et swen, j'ai été pas mal occupé, mais je m'y remets ce
| week-end.

pas de soucis ;)

Pour les autres, un peu de promotion :)
Un antispam tout simple a mettre en oeuvre:
http://www.cnpbagwell.com/projects.html recuperer poppy.pl et sk.pl
--
Kevin
Mais pourquoi ce "rm *.o" prend tant de temps ?
-+- Les 100 choses que vous n'aimez pas entendre de la part du sysadmin -+-