#995 Issue `closed`: better mysql backup, not file based¶

Labels: support / question, fixed / solved / done

phirestalker opened issue at 2016-09-10 21:48:¶

I have a multiple gig mysql database that changes constantly, so everyday I get backup files of 15+ GB. I realized this is happening because as the table file is changed, rear will backup the entire table file again.

I have tried to use rsync, but it is unusable, as it takes more than 12 hours to complete a backup. Is the cifs backup location enough to slow it down that much? Should I do a local backup and use other means to move the files to my main machine for Crashplan backup?

So I am looking for a way to speed up rsync (maybe find the bottleneck) or possibly creating special rules for my mysql database backups? Any other suggestions are welcome.

Relax-and-Recover 1.18 / Git
Distributor ID: Ubuntu
Description: Ubuntu 16.04.1 LTS
Release: 16.04
Codename: xenial

local.conf¶

OUTPUT=ISO
OUTPUT_URL=cifs://192.168.133.138/dataserver
OUTPUT_OPTIONS="cred=/etc/rear/.cifs"
BACKUP=NETFS
EXCLUDE_BACKUP=( "${EXCLUDE_BACKUP[@]}" "fs:/tmp" )
BACKUP_TYPE=incremental
FULLBACKUPDAY="Thu"
BACKUP_URL=cifs://192.168.133.138/dataserver
BACKUP_OPTIONS="cred=/etc/rear/.cifs"* Brief description of the issue

jsmeix commented at 2016-09-23 12:55:¶

In general regarding issues with the backup see what I wrote in
https://github.com/rear/rear/issues/1006

FYI:
Regarding backup data transmission speed:

I did not test varios backup methods but I noticed
that there could be big differences in backup data
transmission speed, see
https://github.com/rear/rear/pull/859#issue-158191489
(excerpt)

At least for me the backup via curlftpfs is
very much slower than the backup via NFS.
For backup via NFS "rear mkbackup" reports
Archived 916 MiB in 163 seconds [avg 5759 KiB/sec]
while in contrast for backup via curlftpfs "rear mkbackup" reports
Archived 916 MiB in 1744 seconds [avg 538 KiB/sec]

jsmeix commented at 2016-09-23 12:59:¶

Furthermore regarding speedup the backup process
by changing the compression level of gzip
you may have a look at
https://github.com/rear/rear/issues/904
therein see in particular my statistics in
https://github.com/rear/rear/issues/904#issuecomment-232685958

jsmeix commented at 2016-09-26 10:39:¶

I think it is sufficiently answered because issues with backup tools
usually do not belong directly to rear.

[Export of Github issue for rear/rear.]