Recommendations, best practices or things tried that worked well. This refers to features of the Wheezy release or later.

ZFS

ZFS has its own Best Practices Guide already.

Snapshots

If /boot is on a ZFS filesystem, you can make snapshots before or after changing the kernel. GRUB is able to boot a kernel and modules from old snapshots (:TODO: syntax).

The autosnap scheme described in /etc/default/zfs is incredibly useful and efficient for often-changing user data such as /home. The 'Towers of Hanoi' or 'logarithmic' scheme balances space taken by the snapshots, with a desire to have a long backup history, preferring to keep recent snapshots which are closer together in time.

Database backups are best written as plain text dumps such as SQL, which ZFS may apply compression to. If you take daily snapshots, simply overwrite the same file each day. The autosnap scheme is suitable here too.

The logrotate.conf option 'dateext' may be a good idea. That avoids renaming old log files each day, and makes it easy to find a particular day's log within snapshots. There is no unnecessary duplication if the same log file gets snapshotted on different days.

The 'nocompress' option can be used for logs saved to filesystems that are already compressed. It is probably not worth recompressing them, unless you need a better compression ratio such as using xz.

Partitioning

It is better to format whole disks (e.g. /dev/da0, /dev/da1) as ZFS, but this is not always possible. You can't install the GRUB bootloader to a disk without partitioning it.

Here are some suggestions:

You can't partition more than 2 TiB of space on a 512-byte sector disk. (4096-byte sector disks allow 16 TiB). Use gpt otherwise.

Alignment on SSD/flash media should not be a problem any more as of Wheezy since most tools snap to a 1 MiB boundary. That should also leave a large enough embedding area for GRUB before the first partition.

The kernel of FreeBSD can't use a logical partition as a root filesystem, or (probably; unconfirmed) as a volume in a ZFS pool. Therefore avoid creating /dev/da0s2 as an extended partition as per MS-DOS/Windows convention and you can instead create up to four(?) primary partitions.

Old (~10 year) PC BIOSes might not support LBA, and so cannot address beyond the 1024th cylinder. On USB flash media that could be only 1 GiB at the start of the disk; on other disks this may be up to 8 GiB. Everything necessary for GRUB (filesystems containing /boot and /lib/modules) needs to be entirely within that region. Otherwise GRUB may hang at boot, or will be unable to find or load kernels or modules, depending on which disk blocks they're stored in.

I recommend that /boot be the first partition. It makes sense because the partition table and GRUB boot blocks are within the first 1 MiB of the disk already.

GRUB will probably need to load kernel modules from /lib/modules. You could either create another special partition for it, or keep it on the root filesystem (subject to the size constraints above), or most conveniently you can move+symlink /lib/modules to /boot/modules (which update-grub2 will detect).

Partitions for ZFS may cause a problem if they extend to the very end of the disk. I suggest deliberately leaving at least 1 MiB of space when partitioning, or just make sure it is not the last partition.

Example of a 80 GiB disk with msdos partition table:

0-1 MiB

MBR and GRUB boot blocks

1-128 MiB

/dev/da0s1

ufs

/boot, containing /boot/modules (symlinked from /lib)

128-1024 MiB

/dev/da0s2

swap

1024 MiB - 81919MiB

/dev/da0s3

zfs

root filesystem

81919-81920MiB

gap

Uunfortunately to see a gpt disk as being bootable, PC BIOS may need a dummy msdos (legacy) partition table, which you can create with gptsync. The constraint mentioned above still applies to old, non-LBA BIOS, so filesystems for /boot and /lib/modules need entries in the legacy partition table, and need to fit entirely within the first 1 GiB of disk (worst case).

GRUB will need a BIOS Boot Partition to install to, which is recommended to be at the start of the disk. It's recommended that the filesystem[s] containing /boot and /lib/modules follow immediately after, to make sure there is space for them in the legacy partition table and within the first 1 GiB of the disk.

The remaining partitions should not be limited in any way. The kernel of FreeBSD understands the gpt partitioning scheme and can mount root and other filesystems from it.

The above mentioned ZFS bug is not an issue with gpt, because the backup partition table will occupy the last LBA-addressable block on the disk.