On Fri, Aug 11, 2017 at 11:08 PM, <siranee...@tpc.co.th> wrote:
> The backup script has the btrfs sync command since Aug 3 >From your script: > system btrfs sub snap -r $basepath $snappath > system btrfs sub sync $basepath >From the man page: sync <path> [subvolid...] Wait until given subvolume(s) are completely removed from the filesystem after deletion. This 'subvolume sync' command, per the man page, is only about subvolume deletion. I suggest replacing it with a regular sync command. I think the problem is that the script does things so fast that the snapshot is not always consistent on disk before btrfs send starts. It's just a guess though. If I'm right, this means the rsync mismaches mean the destination snapshots are bad. Here's what I would do: - delete all the bad/mismatching snapshots only on the destination computer. - he most recent good snapshot pair, which rsync shows origin and destination match, is mysql_201708080830 so you can keep that one on both sides. - manually do incremental send/receive, starting with mysql_201708090830/, to make the destination current again with the origin. - confirm with rsync that the snapshot pairs on origin and destination are the same - now resume using the modified script, which will do snapshot -> sync -> send. OPTIONAL, you could add to your script an rsync -avnc to double check that the incremental send receive is working. This is admittedly inefficient because it checks the *entire* contents of the snapshots on both sides, it's not just checking the incremental data. But if it doesn't take too long, it will help restore trust in send/receive, and confirm that a regular sync is needed in between snapshot and send. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html