On Sun, Aug 13, 2017 at 4:52 AM, <siranee...@tpc.co.th> wrote: > Hi "A L", > > [root@backuplogC7 ~]# btrfs sub show /var/lib/mariadb/mysql > /var/lib/mariadb/mysql > Name: mysql > UUID: 92f319c5-e132-3249-9b13-d39ee77a2b44 > Parent UUID: - > Received UUID: 3ad0334a-4063-654c-add6-b1cbcdeaa639 > Creation time: 2017-06-21 13:27:41 +0700 > Subvolume ID: 257 > Generation: 539 > Gen at creation: 9 > Parent ID: 5 > Top level ID: 5 > Flags: - > Snapshot(s): > mysql_201708060830 > mysql_201708070830 > mysql_201708080830 > mysql_201708090830 > mysql_201708100830 > mysql_201708110830 > mysql_201708120830 > mysql_201708130830 > > yes I think it has Received UUID because I restored the source from snapshot > mysql_201708040830 for prove that the local snapshot was work. > > How to clear the Received UUID ? > What to do next?
I'm using btrfs-progs 4.12, and I just did a btrfs send/receive from file system A to B; and then on B I took a rw snapshot of the ro snapshot. The ro snapshot has Received UUID, but the rw snapshot made from it does not have Received UUID. So now I'm confused how you have a rw snapshot with Received UUID set. Did you ever use 'btrfs property set' to change a ro snapshot to rw? That's the only way I can think it's possible. The only other thing is maybe the behavior has changed since btrfs-progs 4.4. It is possible this behavior has changed since btrfs-progs 4.4. The changelogs shows there are improvements in send/receive in particular 4.8.3 and 4.8.4, but also others. I have no idea which are related. But anyway, this is one of the reasons why the expert users on this almost always say use something newer because it's just too hard to remember, even with changelogs, what's fixed and where. My suggestion is to investigate moving to kernel 4.9 series; and it should be safe to move to btrfs-progs 4.12 now. Any new features in 4.12 that can't be supported with an older kernel should fail gracefully. No matter what, you must have separate backups. You can't depend exclusively on one backup, no matter the method. It's fine to use send/receive for backup1. But backup2 should be a conventional backup, e.g. XFS with rsync. Basically this is a game of risk and the more independent backups you have, the more failure cases (especially user error) you can recover from, at the expense of some complexity. -- 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
