On 2015-10-30 06:58, Duncan wrote:
Unless something has significantly changed since I last looked, send only works on existing snapshots and doesn't create any directly itself, and as such should work fine to send snapshots from a read-only filesystem. In theory, you could use it to send all the snapshots at once, although that would probably take a long time, so you'll probably have to use a loop like the fragment of shell-script that Hugo suggested in his response. That should result in an (almost) identical level of sharing.Lukas Pirl posted on Fri, 30 Oct 2015 10:43:41 +1300 as excerpted:If there is one subvolume that contains all other (read only) snapshots and there is insufficient storage to copy them all separately: Is there an elegant way to preserve those when moving the data across disks?AFAIK, no elegant way without a writable mount. Tho I'm not sure, btrfs send, to a btrfs elsewhere using receive, may work, since you did specify read-only snapshots, which is what send normally works with in ordered to avoid changes to the snapshot while it's sending it. My own use-case doesn't involve either snapshots or send/receive, however, so I'm not sure if send can work with a read-only filesystem or not, but I think its normal method of operation is to create those read-only snapshots itself, which of course would require a writable filesystem, so I'm guessing it won't work unless you can convince it to use the read-only mounts as-is.
If you're using duperemove (which is the only maintained dedupe tool I know of for BTRFS), then this will likely take a long time for any reasonable amount of data, and probably take up more space on the destination drive than it does on the source (while duperemove does block-based deduplication, it uses large chunks by default).The less elegant way would involve manual deduplication. Copy one snapshot, then another, and dedup what hasn't changed between the two, then add a third and dedup again. ... Depending on the level of dedup (file vs block level) and the level of change in your filesystem, this should ultimately take about the same level of space as a full backup plus a series of incrementals.
FWIW, while I don't use them directly myself as a backup, they are useful when doing a backup to get a guaranteed stable version of the filesystem being backed-up (this is also one of the traditional use cases for LVM snapshots, although those have a lot of different issues to deal with). For local backups (I also do cloud-storage based remote backups, but local is what matters in this case because it's where I actually use send/receive and snapshots) I use two different methods depending on the amount of storage I have: 1. If I'm relatively limited on local storage (like in my laptop where the secondary internal disk is only 64G), I use a temporary snapshot to generate a SquashFS image of the system, which I then store on the secondary drive. 2. If I have a lot of spare space (like on my desktop where I have 4x 1TB HDD's and 2x 128G SSD's), I make a snapshot of the filesystem, then use send/receive to transfer that to a backup filesystem on a separate disk. I then keep the original snapshot around on the filesystem so I can do incremental send/receive to speed up future backups. In both cases, I can directly boot my most recent backups if need be, and in the second case, I can actually use it to trivially regenerate the backed-up filesystems (by simply doing a send/receive in the opposite direction).Meanwhile, this does reinforce the point that snapshots don't replace full backups, that being the reason I don't use them here, since if the filesystem goes bad, it'll very likely take all the snapshots with it.
Beyond providing a stable system-image for backups, the only valid use case for snapshots in my opinion is to provide the equivalent to MS Windows' 'Restore Point' feature (which I'm pretty sure is done currently by RHEL and SLES if they are installed on BTRFS) and possibly 'File History' for people who for some reason can't use real VCS or just need to store the last few revision (which is itself done by stuff like 'snapper').
smime.p7s
Description: S/MIME Cryptographic Signature
