On Fri, Oct 13, 2017 at 12:22 PM, Austin S. Hemmelgarn <ahferro...@gmail.com> wrote:
> From a practical perspective, you're almost certainly better off creating a > copy for cold storage without involving BTRFS. Yeah if you want to hedge your bets, and keep it simple, rsync to XFS. With some added risk (double) you can use mdadm linear or LVM to concat multiple devices if necessary. In theory you're not going to get a double failure. But really, the more backups you add, it increasingly doesn't matter what the strategy used. >As an alternative, I would > suggest one of the following approaches: > > 1. Take a snapshot of the filesystem, and use send/receive to transfer that > to another device which you then remove and store somewhere. This is what I do. Primary, and two separate backup (separate volume UUIDs), all three are Btrfs. The primary uses send/receive to the two backups. But my organization plan allows me to have only three subvolumes on the primary being snapshot and thus send/receive. So it's easy. Fourth copy, a subset of important data, is in the cloud. > 2. Use rsync to copy things to another device which you then remove and > store somewhere. A fifth copy, also a subset of important data is done doing this to XFS and a big drive kept offsite. It just accumulates. I don't consider it a backup, it's an archive, nothing is deleted. I treat it as WORM. Maybe one day I redo it based on dm-verity so I can add error detection and correction, the cryptographic aspects are a distant second for me. > Both these options are safer, less likely to screw up your existing > filesystem, and produce copies that can safely be connected to the original > system at the same time as the original filesystem. Keeping it simple is the only way you use it with any regularity, and can understand it well enough if (really when) you have to do a restore. -- 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
