On Sun, Aug 13, 2017 at 4:49 AM, <siranee.ja@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
