Btrfs snapshot to non-btrfs disk. Encryption, read acess

I will just add to Gilles' answer by saying that although you may use “cp, rsync, etc.” to transfer your read-only subvolumes / snapshots, you may also send and store the subvolumes as btrfs streams using the btrfs send command. The btrfs Wiki mentions the following use:

# btrfs subvolume snapshot -r / /my/snapshot-YYYY-MM-DD && sync
# btrfs send /my/snapshot-YYYY-MM-DD | ssh user@host btrfs receive /my/backups
# btrfs subvolume snapshot -r / /my/incremental-snapshot-YYYY-MM-DD && sync
# btrfs send -p /my/snapshot-YYYY-MM-DD /my/incremental-snapshot-YYYY-MM-DD |
    ssh user@host btrfs receive /backup/home

but you may also just save the streams for future use:

# btrfs subvolume snapshot -r / /my/snapshot-YYYY-MM-DD && sync
# btrfs send /my/snapshot-YYYY-MM-DD |
    ssh user@host 'cat >/backup/home/snapshot-YYYY-MM-DD.btrfs'
# btrfs subvolume snapshot -r / /my/incremental-snapshot-YYYY-MM-DD && sync
# btrfs send -p /my/snapshot-YYYY-MM-DD /my/incremental-snapshot-YYYY-MM-DD |
    ssh user@host 'cat >/backup/home/incremental-snapshot-YYYY-MM-DD.btrfs'

This is useful to store the verbatim btrfs snapshots at arbitrary filesystems. The advantage over, say, tar is that btrfs snapshots are incremental and only the delta gets sent. The btrfs Wiki claims that this method of incremental backup tends to be even faster than rsync.

A snapshot (in this sense) is a part of the filesystem. In btrfs terminology, it's a subvolume — it's one of the directory trees on the volume. It isn't in “archive form”. Making a snapshot of a subvolume creates a new subvolume which contains the data of the original volume at the date the snapshot was made. Subsequent writes to the original subvolume don't affect the snapshot and vice versa. All subvolumes are part of the same volume — they designate subsets (potentially overlapping) of the data in the volume.

The parts of the snapshot that haven't been modified in either subvolume share their storage. Creating a snapshot initially requires no storage except for the snapshot control data; the amount of storage increases over time as the content of the subvolumes diverge.

The most important property of snapshot creation is that it's atomic: it takes a picture of the data at a point in time. This is useful to make backups: if the backup program copies files from the live system, it might interact poorly with modifications to the files. For example, if a file is moved from directory A to directory B, but the backup program traversed B before the move and A after the move, the file wouldn't be included in the backup. Snapshots solve this problem: the file will be in A if the snapshot is made before the move and in B if it's made after, but either way it will be there. Then the backup program can copy from the snapshot to the external media.

Since the snapshot is on the same volume as the original, it's stored in the same way, e.g. it's encrypted if the volume is encrypted.

A snapshot reproduces the original directory tree, including permissions and all other metadata. So the permissions are the same as the original. In addition, users must be able to access the snapshot directory itself. If you don't want users to be able to access a snapshot at all, create it under a directory that they can't access (you can place the snapshot anywhere you want).

If you want to make a copy of the snapshot outside the filesystem, access or mount the snapshot then make a copy with your favorite program (cp, rsync, etc.). You can find sample commands in the btrfs wiki; see the manual page for a full reference.