Re: btrfs issue with mariadb incremental backup

[Chris Murphy <lists@colorremedies.com>]

On Sun, Aug 13, 2017 at 4:49 AM,  <siranee.ja@tpc.co.th> wrote:

> [root@backuplogC7 ~]# btrfs send /var/lib/mariadb/mysql_201708090830 | ssh
> 192.168.45.166 btrfs receive /var/lib/mariadb
> At subvol /var/lib/mariadb/mysql_201708090830
> At subvol mysql_201708090830
> [root@backuplogC7 ~]# rsync -avnc /var/lib/mariadb/mysql_201708090830/
> root@192.168.45.166:/var/lib/mariadb/mysql_201708090830/
> sending incremental file list
> ./
>
> sent 3773 bytes  received 19 bytes  842.67 bytes/sec
> total size is 718361496  speedup is 189441.32 (DRY RUN)


OK so the full send is sane. That suggests the file systems on both
sides are OK, and that the problem is related strictly to incremental
send/receive. It suggests that in a critical way either an origin
parent or its copy on the destination are not identical. Why will be
hard to figure out, and I'm not even sure it's worth it.

Right now you basically have a work around: a known good full send,
you can start doing incremental send/receive again using this full
send/receive snapshot as the parent (with -p).

Where confusion can happen is if you have to restore a snapshot, I
think you must commit to a whole new canonical tree with the reverse
send/receive being a full one, NOT incremental. I'm asserting this, I
do not know if it is true, I don't know if the tools should prevent
reverse incremental send/receive, but the very idea of reversing an
incremental send receive to me just seems logically problematic. Any
time you reverse the send/receive direction it must be full. I think.

I did once get into trouble with this myself, having to do a restore
from backup, to a new file system. I then took a rw snapshot of it,
and made that the canonical live modify subvolume. I then ro
snapshotted it, and tried to do an incremental send *back* to backup
and it failed with an error I don't remember but I think it was later
send/receive versions than 4.4 where there's some extract sanity
checking to prevent this. And I was able to work around it with -c
(clone) option. Anyway, I got sufficiently confused myself after all
of that, that I pretty much gave up on such a strategy, blew away all
the ro snapshots on both sides, and started from scratch with a new
full send, and then resumed the incrementals unidirectionally. And
anytime they are reversed I assume it must be a full send.

Anyway, I think it's perilous to reverse directions while also trying
to do incremental send/receive without a lot of testing to thoroughly
understand what's going on. And I basically got to fuck this, not
worth the complexity.

-- 
Chris Murphy