Arnold Krille <email@example.com> wrote on 04/26/2013
> On Thu, 25 Apr 2013 14:45:50 -0700 Lord Sporkton
> <firstname.lastname@example.org> wrote:
> > I'm currently backing up mysql by way of dumping the DB to a
> > file then backing up the flat file. Which works well in most
> > except when someone has a database that is bigger than 50% of
> > hdd. Or really bigger than around say 35% of the hdd if you account
> > for system files and a reasonable amount of free space.
> > I started thinking, mysqldump streams data into a file and then
> > backuppc streams that file for backup. So why not cut out the
> > man file and just stream right into backuppc? Ive been playing
> > the backup commands but im getting some unexpected results due
> > what I believe is my lack of total understanding of how backuppc
> > actually streams things.
> I don't know about your rates, but here in europe a new 2TB-disk costs
> less then me thinking and trying to implement anything like this.
<Speculation about getting data to BackupPC snipped.>
> So unless you have an academic interest in understanding how things
> work, its much cheaper and easier to just push more disk-space into
> servers concerned. Probably its just putting two more disks on the
> and then increasing several machines disks?
I second this. I usually have a Samba share
and an NFS share on my BackupPC box for just this situation (I'm looking
at *you*, Microsoft Exchange). I would have the SQL server dump its
data via SMB/NFS to BackupPC, and then back up that data using the locahost
host on BackupPC. Works fine. The only annoying part is having
to copy the data twice (once across the network and once when BackupPC
backs it up). Ideally, I would **LOVE** a mode where BackupPC simply
hardlinks the source data right into the pool (obviously, my pool and the
shares are on the same partition). If I could do that, there would
be *ZERO* downsides to my method! :)
In fact, I'd pay for that feature.... Jeff or
Holger, any interest? :)