Hi, On 29/06/2018 09:22, Marc MERLIN wrote: > On Fri, Jun 29, 2018 at 12:09:54PM +0500, Roman Mamedov wrote: >> On Thu, 28 Jun 2018 23:59:03 -0700 >> Marc MERLIN <m...@merlins.org> wrote: >> >>> I don't waste a week recreating the many btrfs send/receive relationships. >> Consider not using send/receive, and switching to regular rsync instead. >> Send/receive is very limiting and cumbersome, including because of what you >> described. And it doesn't gain you much over an incremental rsync. As for > Err, sorry but I cannot agree with you here, at all :) > > btrfs send/receive is pretty much the only reason I use btrfs. > rsync takes hours on big filesystems scanning every single inode on both > sides and then seeing what changed, and only then sends the differences > It's super inefficient. > btrfs send knows in seconds what needs to be sent, and works on it right > away.
I've not yet tried send/receive but I feel the pain of rsyncing millions of files (I had to use lsyncd to limit the problem to the time the origin servers reboot which is a relatively rare event) so this thread picked my attention. Looking at the whole thread I wonder if you could get a more manageable solution by splitting the filesystem. If instead of using a single BTRFS filesystem you used LVM volumes (maybe with Thin provisioning and monitoring of the volume group free space) for each of your servers to backup with one BTRFS filesystem per volume you would have less snapshots per filesystem and isolate problems in case of corruption. If you eventually decide to start from scratch again this might help a lot in your case. Lionel -- 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
