That looks like it is coming together. I think it's good to go through it manually once to really understand what you are getting, and to make sure you're getting what you want, but something like zap (where others have spent countless hours ironing out the kinks) is worth considering.
As long as there are multiple datasets and you want to back them all up, you will likely want -R on all of your sends, and just send from the base of the tree. Also look at -I (rather than -i) if you want intermediate snapshots replicated.
You receive into a dataset; its moutpoint is irrelevant.
I like to put in at least a first level filesystem (backup/zdata); it gives you more flexibility in the future (if you have another pool to backup; or want to start a completely new set of backups but retain the first. You will likely need a -F on the initial seeding unless recieving with -e; be sure to do a test recv with -nvF to know what is happening. (Recving zdata@foo into backup with -e will cause backup/zdata to spring into existence and no -F will be required to write over an existing dataset... if I recall; when in doubt, check with -nv)
Using altroot is fine for initial setup, and potentially if this is an external drive that is only occasionally attached; but if it stays attached, you will want to modify the mountpoint properties of the backup such that it can coexist (sans altroot) with zdata. Receive with -u any time you are concerned and double-check mountpoints before mounting. Recall you can still modify the properties (metadata) of a read-only (at the posix/data layer) dataset.
You'll have to export it after creation before you can import altroot, or you can add the altroot to the create, if I recall... (it is never a persistent property, however.)
As far as "restoring" backups, that depends on the use case. A few things to remember:
1) unless you delete them, your snapshots are still available on zdata. The easiest "restore" is to copy files you need out of the appropriate .zfs snapdir. (Shameless plug: I like my own tool
https://github.com/eborisch/zfs_versions for doing that.) Or rollback to the snapshot if you want to discard all changes since then. Be mindful of what state your backup is in (what snapshots exist on it) if you rollback; you may need to rollback the backup as well to a common starting point for the next incremental update.
2) if you've deleted the snapshots on zdata, but retain them on backup, you can pull individual files of out backup's snapdirs. (Or use a tool like rsync for entire directory trees, also potentially within a snapdir if you want an older version.)
3) Sending from your backup would typically only be called for if zdata has a catastrophic failure and/or the drive is replaced / pool recreated.
It (send from backup) can also be used if you want to revert everything in a filesystem to an older (but deleted on zdata) snapshot; you would need to rollback zdata the the newest existing-on-both-sides snapshot older than the desired, and then do an incremental update to the desired sent from backup. In my experience this is rare; you likely either want to rollback to a recent (and still existing on the source; no need to send, just rollback) snapshot, or only want to retrieve a few specific files / directories from an old state.
Check your sends first with -nv, and then check your recvs with -nv (turn it off on the send, obviously) the first few times to make sure you know what is happening before you have it actually "do" anything and you'll have this down in no time!
I think I covered everything. Good luck!
maybe I just need a really in-depth book to get this stuff more