De :
Bruno Friedmann <[email protected]>
À :
claude baryo <[email protected]>
Envoyé le :
Mardi 13 mars 2012 17h48
Objet :
Re: [Bacula-users-fr] Re : Comment reduire le temps de
backup avec Bacula 5.2.6
On Tuesday 13 March 2012 14.57:56 claude baryo wrote:
> Merci à tous pour vos reponses.
>
> trouvez ci-dessous les elements de reponse à vos
interrogations :
>
> - compression activé : GZIP
> - débit observé sur le disque : je ne dispose pas
d'outil pour pouvoir le mesurer (si qlq en dispose, je suis
prenneur)
> Néanmoins j'avais effectué une test de temps de lecture
du disque via la commande
> # hdparm -tT /dev/sdb1
> /dev/sda: Timing buffer-cache reads: 4790 MB in 2.00
seconds =2396.65 MB/sec
> Timing buffered disk reads: 254 MB in 3.01 seconds =
84.44 MB/sec
> - charge cpu : j'ai installé le package "atop" sur mon
serveur.
> j'ai constaté que bacula consommait moins de 2% de CPU
et de Mémoire
>
> Si quelqu'un dispose d'une autre méthode d'analyse, je
suis tjrs preneurs
>
> - configuration de stockage au niveau de la VM : En
fait depuis le client Vsphere, j'ai tout simplement ajouter
un second disque pour pouvoir s'en servir comme storage
Device de Bacula ...
>
> voilà. à votre disposition pour des précisions
complémentaires...
>
>
> Claude B
>
>
>
>
>
>
> ________________________________
> De : "
[email protected]"
<
[email protected]>
> À : Buschini Edouard <
[email protected]>
> Cc : claude baryo <
[email protected]>;
[email protected]
> Envoyé le : Mardi 13 mars 2012 14h58
> Objet : Re: [Bacula-users-fr] Comment reduire le temps
de backup avec Bacula 5.2.6
>
>
> Bonjour,
>
> 200 Go en 11 heures, normal !?
> D'après mes calculs, et avec un débit de 50 Mo/s
> (un débit tout à fait normal sur les disques actuels)
> ces 200 Go devraient être copiés en un peu plus d'une
heure.
> Avec ma configuration de bacula, il doit me falloir à
peu
> près deux heures pour sauvegarder cette quantité de
données.
>
> Il y a donc clairement un problème, reste à trouver à
quel niveau.
> Mais il nous manque bien trop d'informations pour faire
un diagnostique.
>
> (compression activé, oui ou non, quel est le débit
observé sur le disque
> en écriture, est il stable, quel est la charge cpu,
comment est configuré
> le stockage au niveau de la VM (disque virtuel ou réel)
etc etc...
>
> Cdlt,
>
> ----- Buschini Edouard <
[email protected]> a
écrit :
> > Bonjour Claude !
> >
> > Tu as plusieurs façons d'améliorer le temps :
> > - Vérifie le débit entre ton Storage Daemon et
ton File Daemon, si tes
> > sauvegardes se font sur un deuxième disque, il se
peut que l'écriture soit
> > un peut lente.
> > - Si tu n'y tiens pas, enlève la compression au
niveau du fileset dans la
> > configuration de ton Director
> > - Evite de mettre une taille maximal dans ton
spool car si le spool est
> > plein il va devoir déspooler pour insérer les
données dans les bons volumes
> >
> > Mais je ne te conseil pas d'enlever la
compression, bien qu'elle se fasse
> > au niveau client et que ça prends beaucoup de ton
proc, c'est une option
> > bien utile.
> > Sinon 200go pour 11 heures je trouve ça largement
raisonnable et je ne
> > pense pas que même de la copie toute bête soit
beaucoup plus rapide.
> >
> > Le 13 mars 2012 12:34, claude baryo <
[email protected]> a
écrit :
> >
> > > Bonjour à tous,
> > >
> > > J'ai installé et configurer Bacula 5.2.6 sur
un Debian Squeeze d'une
> > > VMWare.
> > > Les sauvegardes se font sur un deuxième
disque dure...
> > >
> > > Problème : Je trouve que le backup de 200 g
prend trop de temp (environ 11
> > > heures )
> > >
> > > comment faire pour reduire sensiblement le
temps de sauvegarde ?
> > >
> > > cordialement
> > >
> > --
> > Edouard Buschini - Rentabiliweb Telecom
C'est quoi la base de donnée utilisée
Le backup sous VM n'est et ne sera jamais la meilleure
performance. Dans un cas d'utilisation pro et intensive
le Director la db et le storage ont tout intérêt à être sur
du bare métal.
Ensuite un test hdparm ne donne absolument aucune
indication. Si des disques peuvent sortir linéairement du
130Mo
c'est pas le cas si ils ont des millions de petits fichiers
à sauver/lire/copier comme des emails par exemple.
Ici on sauve 1.2To + 145Go en ~9 heures sur du sata-e mais
c'est partout du bare-metal. et la db c'est du postgresql
correctement paramétrée.
Donc premier test, copie brute cp entre source et
destination calcul du temps = estimation de ce que la vm est
capable de faire en natif.
Pas s'étonner que les résultats soit mauvais.
:-)
--
Bruno Friedmann
Ioda-Net Sàrl
www.ioda-net.ch
openSUSE Member & Ambassador
GPG KEY : D5C9B751C4653227
irc: tigerfoot
