From: Bruno F. <br...@io...> - 2012-05-10 16:18:04
|
On Thursday 10 May 2012 15.38:39 Buschini Edouard wrote: > Je reste partisan de déporter le système de sauvegarde du catalogue de > Bacula. Faire un dump ascii de toute la db facilite énormément les choses. > > Le 10 mai 2012 15:15, Stéphane Mourey > <ste...@im...>a écrit : > > > A choisir entre faire une sauvegarde du catalogue avant ou après une autre > > sauvegarde, il vaut mieux la faire après. Comme les données sont plus à > > jour. Et si on a un gros problème pendant la sauvegarde avec celle du > > catalogue? il reste toujours la précédente... qui est à jour des > > sauvegardes réussies, quoiqu'il se soit passé depuis. > > Et le plus simple et d'ajouter un rsync / cp juste avant le cleanup. D'après mes tests aussi et expérience de restore après crash. le mode de backup pour des bases postgresql est particulièrement lent sur en restauration : temps de décompression du bz2 import dans la db. Pour ma part, j'utilise maintenant une version modifiée utilisant pg_dump -Fc j'obtiens la compression par la db, et surtout la possibilité de faire travailler plusieurs agent en mode pg_restore Même si c'est souvent la table Files qui est le goulet. Dans le même ordre d'idée : créer un spool spécifique pour le catalogue. avec plusieurs copie à instant t du backup de la db. Pourquoi : en cas de corruption de la db qui n'est pas vu tout de suite, et dont les enregistrements ne sont plus utilisable il est toujours beaucoup plus facile de repartir d'une db saine daté d'une semaine ou d'un mois puis un bscan des volumes manquants que de devoir reconstruire toute la db avec bscan -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot |