-----Message d'origine-----
De: "François" TOURDE [mailto:fra-duf-no-spam@tourde.org]
Envoyé: lundi 25 juin 2007 19:26
À: debian-user-french@lists.debian.org
Objet: Re: Vitesse de restauration

Le 13689ième jour après Epoch,
D. Bacquez écrivait:

> Sur un lecteur de bande VXA-320 j’ai sauvegardé en tar environ 30Go de
> données perso. Suite à un bg j’ai fait un bete « tar xf /dev/st0
> home/…/monfichier « et il y est depuis le debut de l’apres midi, soit y’a
> 3h. Pour un fichier de 8Mo je trouve ça fort de café.

Si ta sauvegarde est "monolithique", alors c'est normal. Il va devoir
parcourir - et donc lire - l'ensemble de la sauvegarde pour extraire
le fichier. Y compris si le fichier est en début, car il faut être sûr
que le fichier en question n'est pas présent plus loin sur la bande.

>> Y’a-t-il un moyen
>> d’accélerer mes lectures/restauration ?

>Utiliser des sauvegardes "fragmentées" à coup de wtm et autres fsm et
>fsf ... man mt pour avoir plus d'infos.

>Si tu veux plus de détails, n'hésites pas à me le faire savoir, il me
>reste encore quelques vagues souvenir de l'époque où j'en déroulais
>des kilomètres

Si j'ai bien compris je vais devoir diviser ma sauvegarde en plusieurs
morceaux tar.
tar cvf /dev/st0 /rep1
tar cvf /dev/st0 /rep2
....

Et pour restaurer j'uilise "mt -f /dev/nftape fss X" avec X le nombre de tar
a sauter pour atteindre le bon
Isn' t it?
Enfin je crois, car je sais pas si lorsque je mets les tar à la suite, il va
en créer plusieurs a la suite.

Sinon j'ai entrevu et survolé dump. Mais ca "m'ennerve" de rechanger de
logiciel d'archivage.

Le 13689ième jour après Epoch,
D. Bacquez écrivait:

> -----Message d'origine-----
> DeÂ: "François" TOURDE [mailto:fra-duf-no-spam@tourde.org]
> EnvoyéÂ: lundi 25 juin 2007 19:26
> ÀÂ: debian-user-french@lists.debian.org
> ObjetÂ: Re: Vitesse de restauration
>
> Le 13689ième jour après Epoch,
> D. Bacquez écrivait:
>
>> Sur un lecteur de bande VXA-320 j’ai sauvegardé en tar environ30Go de
>> données perso. Suite à un bg j’ai fait un bete « tarxf /dev/st0
>> home/…/monfichier « et il y est depuis le debut de l’apres midi, soit y’a
>> 3h. Pour un fichier de 8Mo je trouve ça fort de café.
>
> Si ta sauvegarde est "monolithique", alors c'est normal. Il va devoir
> parcourir - et donc lire - l'ensemble de la sauvegarde pour extraire
> le fichier. Y compris si le fichier est en début, car il faut être sûr
> que le fichier en question n'est pas présent plus loin sur la bande.
>
>>> YÂ’a-t-il un moyen
>>> d’accélerer mes lectures/restauration ?
>
>>Utiliser des sauvegardes "fragmentées" à coup de wtm et autres fsm et
>>fsf ... man mt pour avoir plus d'infos.
>
>>Si tu veux plus de détails, n'hésites pas à me le faire savoir, il me
>>reste encore quelques vagues souvenir de l'époque où j'en déroulais
>>des kilomètres
>
> Si j'ai bien compris je vais devoir diviser ma sauvegarde en plusieurs
> morceaux tar.
> tar cvf /dev/st0 /rep1
> tar cvf /dev/st0 /rep2

Oui, à ceci près qu'il faut que tu utilises /dev/stn0 ou quelque chose
d'approchant, pour dire au pilote de ne pas rembobinner la bande après
le tar.

Je te conseille aussi d'écrire une marque après le tar, toujours sur
/dev/stn0 pour les mêmes raisons.

> Et pour restaurer j'uilise "mt -f /dev/nftape fss X" avec X le nombre de tar
> a sauter pour atteindre le bon
> Isn' t it?

C'est l'idée

> Sinon j'ai entrevu et survolé dump. Mais ca "m'ennerve" de rechangerde
> logiciel d'archivage.

C'est dommage, car il existe plein d'outils qui prennent en charge
eux-même ce genre de traitement, mieux qu'à la main.

Le 13689ième jour après Epoch,
D. Bacquez écrivait:

> -----Message d'origine-----
> DeÂ: "François" TOURDE [mailto:fra-duf-no-spam@tourde.org]
> EnvoyéÂ: lundi 25 juin 2007 19:26
> ÀÂ: debian-user-french@lists.debian.org
> ObjetÂ: Re: Vitesse de restauration
>
> Le 13689ième jour après Epoch,
> D. Bacquez écrivait:
>
>> Sur un lecteur de bande VXA-320 j’ai sauvegardé en tar environ30Go de
>> données perso. Suite à un bg j’ai fait un bete « tarxf /dev/st0
>> home/…/monfichier « et il y est depuis le debut de l’apres midi, soit y’a
>> 3h. Pour un fichier de 8Mo je trouve ça fort de café.
>
> Si ta sauvegarde est "monolithique", alors c'est normal. Il va devoir
> parcourir - et donc lire - l'ensemble de la sauvegarde pour extraire
> le fichier. Y compris si le fichier est en début, car il faut être sûr
> que le fichier en question n'est pas présent plus loin sur la bande.
>
>>> YÂ’a-t-il un moyen
>>> d’accélerer mes lectures/restauration ?
>
>>Utiliser des sauvegardes "fragmentées" à coup de wtm et autres fsm et
>>fsf ... man mt pour avoir plus d'infos.
>
>>Si tu veux plus de détails, n'hésites pas à me le faire savoir, il me
>>reste encore quelques vagues souvenir de l'époque où j'en déroulais
>>des kilomètres
>
> Si j'ai bien compris je vais devoir diviser ma sauvegarde en plusieurs
> morceaux tar.
> tar cvf /dev/st0 /rep1
> tar cvf /dev/st0 /rep2

Oui, à ceci près qu'il faut que tu utilises /dev/stn0 ou quelque chose
d'approchant, pour dire au pilote de ne pas rembobinner la bande après
le tar.

Je te conseille aussi d'écrire une marque après le tar, toujours sur
/dev/stn0 pour les mêmes raisons.

> Et pour restaurer j'uilise "mt -f /dev/nftape fss X" avec X le nombre de tar
> a sauter pour atteindre le bon
> Isn' t it?

C'est l'idée

> Sinon j'ai entrevu et survolé dump. Mais ca "m'ennerve" de rechangerde
> logiciel d'archivage.

C'est dommage, car il existe plein d'outils qui prennent en charge
eux-même ce genre de traitement, mieux qu'à la main.

-----Message d'origine-----
De: "François" TOURDE [mailto:fra-duf-no-spam@tourde.org]
Envoyé: mardi 26 juin 2007 11:00
À: debian-user-french@lists.debian.org
Objet: Re: TR: Vitesse de restauration


Oui, à ceci près qu'il faut que tu utilises /dev/stn0 ou quelque chose
d'approchant, pour dire au pilote de ne pas rembobinner la bande après
le tar.

Je te conseille aussi d'écrire une marque après le tar, toujours sur
/dev/stn0 pour les mêmes raisons.

C'est dommage, car il existe plein d'outils qui prennent en charge
eux-même ce genre de traitement, mieux qu'à la main.

Stn0? Connait pas cette bete là.

Pleins d'outils? Tu parles de backuppc je suppose? Le truc que j'ai jamais
réussi à installer correctement. Rien que le fait que l'administration se
faisait sur une machine distante, et non en localhost, il a jamais compris.
J'ai preferé monter un script moi-même.
Mais si tu me proposes un truc simple, qui marche sur une interface web
aussi facile a installer que webmin, avec laquelle je gere completement mes
sauvegardes et mes resto, je prend.

-----Message d'origine-----
De: "François" TOURDE [mailto:fra-duf-no-spam@tourde.org]
Envoyé: mardi 26 juin 2007 11:00
À: debian-user-french@lists.debian.org
Objet: Re: TR: Vitesse de restauration


Oui, à ceci près qu'il faut que tu utilises /dev/stn0 ou quelque chose
d'approchant, pour dire au pilote de ne pas rembobinner la bande après
le tar.

Je te conseille aussi d'écrire une marque après le tar, toujours sur
/dev/stn0 pour les mêmes raisons.

C'est dommage, car il existe plein d'outils qui prennent en charge
eux-même ce genre de traitement, mieux qu'à la main.

Stn0? Connait pas cette bete là.

Pleins d'outils? Tu parles de backuppc je suppose? Le truc que j'ai jamais
réussi à installer correctement. Rien que le fait que l'administration se
faisait sur une machine distante, et non en localhost, il a jamais compris.
J'ai preferé monter un script moi-même.
Mais si tu me proposes un truc simple, qui marche sur une interface web
aussi facile a installer que webmin, avec laquelle je gere completement mes
sauvegardes et mes resto, je prend.

Le 13690ième jour après Epoch,
D. Bacquez écrivait:

> Stn0? Connait pas cette bete lÃ.

Le nom est peut-être erroné. Cherche dans ton /dev un périphde même
major number, avec un minor différent.

A l'époque (et ça a peut-être changé depuis) il existait plusieurs
périphs "virtuels" associés à un lecteur de bandes, selon qu'on
voulait rembobiner au close, compresser, ou ni l'un ni l'autre.

> Pleins d'outils? Tu parles de backuppc je suppose? Le truc que j'ai jamais
> réussi à installer correctement. Rien que le fait que l'administration se
> faisait sur une machine distante, et non en localhost, il a jamais compris.
> J'ai preferé monter un script moi-même.
> Mais si tu me proposes un truc simple, qui marche sur une interface web
> aussi facile a installer que webmin, avec laquelle je gere completement mes
> sauvegardes et mes resto, je prend.

Je ne parle de rien en particulier, mais j'ai entendu parler (lu
écrire ?) sur cette liste de plusieurs outils de sauvegardes. A toi de
chercher par toi-même

PS: Ta manière de quoter les messages est mauvaise et oblige Ã
"piocher" pour savoir qui dit quoi. Merci de faire un petit effort Ã
ce sujet

Le 13690ième jour après Epoch,
D. Bacquez écrivait:

> Stn0? Connait pas cette bete lÃ.

Le nom est peut-être erroné. Cherche dans ton /dev un périphde même
major number, avec un minor différent.

A l'époque (et ça a peut-être changé depuis) il existait plusieurs
périphs "virtuels" associés à un lecteur de bandes, selon qu'on
voulait rembobiner au close, compresser, ou ni l'un ni l'autre.

> Pleins d'outils? Tu parles de backuppc je suppose? Le truc que j'ai jamais
> réussi à installer correctement. Rien que le fait que l'administration se
> faisait sur une machine distante, et non en localhost, il a jamais compris.
> J'ai preferé monter un script moi-même.
> Mais si tu me proposes un truc simple, qui marche sur une interface web
> aussi facile a installer que webmin, avec laquelle je gere completement mes
> sauvegardes et mes resto, je prend.

Je ne parle de rien en particulier, mais j'ai entendu parler (lu
écrire ?) sur cette liste de plusieurs outils de sauvegardes. A toi de
chercher par toi-même

PS: Ta manière de quoter les messages est mauvaise et oblige Ã
"piocher" pour savoir qui dit quoi. Merci de faire un petit effort Ã
ce sujet

Bonjour,


Le mardi 26 juin 2007, François TOURDE a écrit...


> > Stn0? Connait pas cette bete lÃ.

> Le nom est peut-être erroné. Cherche dans ton /dev un périph de même
> major number, avec un minor différent.

nst0

--
jm

A.E.L. Sarl (R.C.S CASTRES 490843240)
http://www.affaires-en-ligne.com



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Bonjour,


Le mardi 26 juin 2007, François TOURDE a écrit...


> > Stn0? Connait pas cette bete lÃ.

> Le nom est peut-être erroné. Cherche dans ton /dev un périph de même
> major number, avec un minor différent.

nst0

--
jm

A.E.L. Sarl (R.C.S CASTRES 490843240)
http://www.affaires-en-ligne.com



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org