I didn’t mention in the post, but I used innodb_track_changed_pages available in PS and PXC to make the incrementals a lot faster. https://www.percona.com/doc/percona-server/5.6/management/changed_page_tracking.html However, this would not help much if the churn in the database is high.

One idea we realized is that you _never_ have to make a full backup again (if all works fine):

1) make full backup to dir “1”
2) make incrementalt to dir “n”
3) if “n” > n-max end!
4) make full backup by an restore run to an archive (complete roll forwards, step by step…)
(not mentioned to pause between incremental backup runs…)
5) the result is also a “full backup” stored (full prepare) in dir “1”

This also works fine by using qpress (which you _should_ use due to filesize and restoring speed)

I scripted something like a robot, which runs on all nodes which copies its data to a central fileserver/storage.

I found out there are some things to know:
– if your data changes once a day (many updates), the incremental steps could be as big as a full backup which depends on the frequency of backups (pause time)
– if you got a extremly large database but which data not changes much, incremental backup is best you could do