Le 13689ième jour après Epoch, D. Bacquez écrivait: > -----Message d'origine----- > De : "François" TOURDE [mailto:[EMAIL PROTECTED] > Envoyé : lundi 25 juin 2007 19:26 > À : [email protected] > Objet : Re: Vitesse de restauration > > Le 13689ième jour après Epoch, > D. Bacquez écrivait: > >> Sur un lecteur de bande VXA-320 jai sauvegardé en tar environ 30Go de >> données perso. Suite à un bg jai fait un bete « tar xf /dev/st0 >> home/ /monfichier « et il y est depuis le debut de lapres midi, soit ya >> 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. > >>> Ya-t-il un moyen >>> daccé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 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.
