On Fri, Aug 22, 2014 at 3:35 AM, Duncan <1i5t5.duncan@xxxxxxx> wrote: > > No claim to be a dev, btrfs or otherwise, here, but I believe in this > case you /are/ "being too paranoid." > > Both btrfs send and receive only deal with data/metadata they know how to > deal with. If it's corrupt in some way or if they don't understand it, > they don't send/write it, they fail. > > IOW, if it works without error it's as guaranteed to be golden as these > things get. The problem is that it doesn't always work without error in > the first place, sometimes it /does/ fail. In that instance you can > always try again as the existing data/metadata shouldn't be damaged, but > if it keeps failing you may have to try something else, rsync, etc. Well, my main use-case for rsync right now is btrfs bug hoses my filesystem, so it would be nice to have a daily full backup on something other than btrfs so that it is unlikely to suffer the same problem at the same time. Using btrfs send with that backup would certainly be more efficient, but it would defeat the purpose of the backup, which is to not be btrfs. I am already using mirroring in the event of drive failure, and offsite cloud backups of critical data in the event of a larger catastrophe. Btrfs eating my data is a somewhat likely failure mode in the grand scheme of things, so I protect against it so that I can still have fun playing with btrfs without losing sleep. I've actually restored from it once. I suspect that I could have fixed my ENOSPC problem without resorting to that, but the usual FAQ solutions didn't work and I was running short on time, and that particular filesystem was only 64GB anyway so it was a fast restore (and that is why this filesystem is prone to ENOSPC in the first place). Oh, and I'm using rsnapshot, so I also get the benefit of a few days worth of backups - almost as good as snapper, though in reality obviously not the same thing. -- Rich -- 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
