J'avoue que j'ai pris en charge le projet que depuis la semaine dernière et je ne connaissais rien de Bacula.

Pour repondre à votre question, la Db utilisée est postgresql 9.1.2 installé sur la même VM que le director Bacula...
Quel est à votre avis, le paramétrage correct ou efficient de postgresql ?

Pour votre info, cette config est dans le cadre de test avant de prendre la décision d'implémenter bacula en prod.

cordialement



De : Bruno Friedmann <bruno@ioda-net.ch>
À : claude baryo <cloba1@yahoo.fr>
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 : "hoper@free.fr" <hoper@free.fr>
> À : Buschini Edouard <moon@ijaal.net>
> Cc : claude baryo <cloba1@yahoo.fr>; bacula-users-fr@lists.sourceforge.net
> 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 <moon@ijaal.net> 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 <cloba1@yahoo.fr> 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