From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f43.google.com ([209.85.213.43]:35341 "EHLO mail-vk0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751819AbdHLVeC (ORCPT ); Sat, 12 Aug 2017 17:34:02 -0400 Received: by mail-vk0-f43.google.com with SMTP id d124so22747980vkf.2 for ; Sat, 12 Aug 2017 14:34:02 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1420.49.228.123.163.1502514511.squirrel@mail> References: <21234.192.168.42.222.1502253143.squirrel@mail> <22169.183.88.87.49.1502260598.squirrel@mail> <27218.183.88.87.49.1502426431.squirrel@mail> <13031.192.168.42.222.1502431206.squirrel@mail> <1243.49.228.123.163.1502505534.squirrel@mail> <1420.49.228.123.163.1502514511.squirrel@mail> From: Chris Murphy Date: Sat, 12 Aug 2017 15:34:01 -0600 Message-ID: Subject: Re: btrfs issue with mariadb incremental backup To: siranee.ja@tpc.co.th Cc: Chris Murphy , Btrfs BTRFS , voravat@tpcorp.co.th Content-Type: text/plain; charset="UTF-8" Sender: linux-btrfs-owner@vger.kernel.org List-ID: On Fri, Aug 11, 2017 at 11:08 PM, 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 [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