On Fri, Aug 11, 2017 at 11:08 PM, <siranee.ja@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
