[CentOS] Backup solution to backup /var/spool/imap above 150GB data

Wed Feb 24 11:24:26 UTC 2010
Agnello George <agnello.dsouza at gmail.com>

On Wed, Feb 24, 2010 at 4:13 PM, Gavin Carr <gavin at openfusion.com.au> wrote:

> On Wed, Feb 24, 2010 at 10:38:32AM +0100, David Hrbáč wrote:
> > Dne 24.2.2010 10:00, Agnello George napsal(a):
> > > We have  an issue with one of our clients , they have a mail server
> with
> > > the  /var/spool/imap partition as 150 GB . They need to take
> differential
> > > backup on to /backup partition ( a different HDD  of total 250 GB space
> )  .
> > > We have tried dar , rsync, rdiff and impasync . But its is not
> sufficing the
> > > need as to take a lot of time and consumes a lot of I/O .
> > >
> > > Is there any back up solution that you can think of , that can work in
> this
> > > situation  - open source or proprietary
> >
> > Is seems to me, that you are using mbox format. So, differential backup
> > is hard to achieve. Migrate to maildir, every mail is a file, easy to
> > backup differentially.
>
> rsync and rdiff should handle mbox format okay though. Though I agree
> Maildir
> is generally nicer for differential backups.
>
> Agnello, how long is "a lot of time"? A backup is always going to have to
> walk
> the entire tree and checksum (or at least stat) every file, so there's a
> minimum
> cost you're always going to have. How long does a 'find /var/spool/imap
> -ls'
> take, for instance?
>
> You might want to try brackup (http://code.google.com/p/brackup/). For
> very
> large trees of relatively small files it seems to significantly out-perform
> rsync-based backups. I've got brackup packages in my repository (see
> http://www.openfusion.net/linux/openfusion_rpm_repository).
>
> Cheers,
> Gavin
>
>  <http://lists.centos.org/mailman/listinfo/centos>
>
is it possible with " brackup "  <http://code.google.com/p/brackup/> to back
it up to a different server on the same lan   instead of /backup  . Is there
any documentation on the same .


-- 
Regards
Agnello D'souza
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos/attachments/20100224/939820f3/attachment-0005.html>