On Fri, Apr 26, 2013 at 5:31 PM,  <backuppc AT kosowsky DOT org> wrote:
> >
> Precisely... if you just have a few (as in o(100)) large database
> files then you don't need all the complexity of BackupPC which comes
> at the cost of speed, etc. And the pooling part which is perhaps the
> main differentiator of BackupPC probably won't even come into play at
> all since even a 1 bit change to a 50-200GB database will require an
> entire new copy.
>
> I would do what Les suggests in conjunction with compression (if you
> truly are using mysqldump to output an ascii flat file) plus a
> filesystem like zfs with block de-duplication. BackupPC seems like the
> wrong nail for the hammer...

An interesting - and simple - approach that might work would be to
feed the uncompressed DB dump to split (in a unique directory per run)
and then look at how much pooling backuppc can do with the resulting
chunks over time.  I don't have any idea what might be the ideal
output file size, though.

--
   Les Mikesell
     lesmikesell AT gmail DOT com

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/