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

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

- 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

Reply via email to