[Discuss] ZFS for an Encrypted External Disk: My Experience and Notes

[Dan Ritter]

Kent Borg wrote: 
>   zpool create extern_backup_pool /dev/sda
>   zpool export extern_backup_pool

zpool export prepares a pool to be used on a different machine -
for an external portable disk, you might do this in order to
unmount it.

You definitely don't need to do that right after you create

>   zpool import -d
> /dev/disk/by-id/usb-WD_My_Passport_260D_575843324442314A5558354B-0:0-part1
> extern_backup_pool -N

You only need to import it if you have just attached it.

zpool import by itself should list all detected zpools by name,
at which point zpool import $name  will work.

>   zpool status
>   zfs set compression=on extern_backup_pool

That sets a default. It's a good default, but it can be changed
per-zfs.

>   zfs set mountpoint=/zfs_mounts/extern_backup_pool extern_backup_pool
>   zfs create -o encryption=on -o keylocation=prompt -o keyformat=passphrase
> extern_backup_pool/extern_backup_dataset
> 
> Enter passphrase. Then:
> 
>   zfs get mountpoint

The default mountpoint for a newly created zfs is right under
where you mounted the root of the pool, which you had just reset
from /extern_backup_pool to /zfs_mounts/extern_backup_pool.

You can set the mountpoint for any zfs independently of the
pool -- i.e. you could have a /opt.

>   zfs unmount extern_backup_pool/extern_backup_dataset && zpool export
> extern_backup_pool

The export is to prep for unplugging. If you're not going to
unplug, just the unmount will do. If you are going to unplug,
the export will start by unmounting everything.

> To mount do:
> 
>   zpool import -d /dev/disk/by-id extern_backup_pool && zfs mount -l
> extern_backup_pool/extern_backup_dataset

A zpool import will mount every zfs it contains by default. You
can turn that off per-zfs.

The names, as I said, can be simplified.


> Noticing errors along the way is a good thing, but backups are a
> write-mostly operation for changing data, so the ability to check the entire
> disk contents for failures is also appealing. I haven't decided how often to
> do this. My disk holds less than 1TB currently, and it took over three-hours
> to scrub, as it gets fuller it will take longer—plus the wear and tear of
> frequently reading everything seems a real concern—so I won't do it every
> time I do a backup. For the moment I think I will paste the output of the
> zpool status into a log file at the root of each disk to keep track of when
> I have scrubbed it.

There shouldn't be much wear-and-tear on just reading all the
data on the disk. Still, I wouldn't bother doing it more than
once a month.

zpool status is durable for things like that, you don't need to
write it into a log.

You can see quite a lot of interesting filesystem events via 
zdb -h $pool

including scrubs and snapshots.

-dsr-