Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

TR: Vitesse de restauration

1 réponse
Avatar
D. Bacquez
-----Message d'origine-----
De=A0: "Fran=E7ois" TOURDE [mailto:fra-duf-no-spam@tourde.org]=20
Envoy=E9=A0: lundi 25 juin 2007 19:26
=C0=A0: debian-user-french@lists.debian.org
Objet=A0: Re: Vitesse de restauration

Le 13689i=E8me jour apr=E8s Epoch,
D. Bacquez =E9crivait:

> Sur un lecteur de bande VXA-320 j=92ai sauvegard=E9 en tar environ =
30Go de
> donn=E9es perso. Suite =E0 un bg j=92ai fait un bete =AB tar xf =
/dev/st0
> home/=85/monfichier =AB et il y est depuis le debut de l=92apres =
midi, soit y=92a
> 3h. Pour un fichier de 8Mo je trouve =E7a fort de caf=E9.

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=E9but, car il faut =EAtre =
s=FBr
que le fichier en question n'est pas pr=E9sent plus loin sur la bande.

>> Y=92a-t-il un moyen
>> d=92acc=E9lerer mes lectures/restauration ?=20

>Utiliser des sauvegardes "fragment=E9es" =E0 coup de wtm et autres fsm =
et
>fsf ... man mt pour avoir plus d'infos.

>Si tu veux plus de d=E9tails, n'h=E9sites pas =E0 me le faire savoir, =
il me
>reste encore quelques vagues souvenir de l'=E9poque o=F9 j'en =
d=E9roulais
>des kilom=E8tres ;)

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 =E0 la suite, =
il va
en cr=E9er plusieurs a la suite.

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

1 réponse

Avatar
fra-duf-no-spam
Le 13689ième jour après Epoch,
D. Bacquez écrivait:

-----Message d'origine-----
De : "François" TOURDE [mailto:]
Envoyé : lundi 25 juin 2007 19:26
À :
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’apr es 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 sa voir, 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 rechanger de
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.