First you'll need to create an empty pool on Server A. zfs recv cannot create a new pool. So on Server A:
zpool create -R /mnt zfs49 [ mirror diskID1 diskID2 ]
... or some other VDEV structure of your choice. The VDEV structure on Server A doesn't need to match whatever the old structure was of the pool you lost. It just needs to be large enough to hold the data. So if you've gained experience from the choices you made last time, feel free to make better choices when creating the pool this time. But yeah, if you are using 4k-native drives, you'll still want ashift=12 etc.
Also, I gather from your comment below that the pool and filesystem names will be the same, so we will restore pool zfs49 filesystem tank on server B, to pool zfs49 filesystem tank on server A.
Rather than transfer each filesystem explicitly, it is probably beneficial to illustrate how to use a recursive snapshot to transfer the entire pool, including all filesystems, and their snapshots.
After you've created the empty pool on Server A above, the next step is to make an up-to-date recursive snapshot on Server B. This snapshot will be chiefly for the purpose of this one-time restore job, and thus does not need to match your naming scheme of YYYYMonDDHHMM. In fact, insofar as this restore job snapshot is likely to be short-lived, it may help to have it stick out from the others.
I propose that you create a recursive snapshot on Server B and name it xfer, to be used for the specific purpose of this one time transfer. So on Server B:
zfs snap -r zfs49@xfer
Now, since you have a pristine (empty, blank) pool on Server A named zfs49, you can transfer that recursive snapshot from Server B to Server A, beginning from Server B:
zfs send -R zfs49@xfer | ssh <Server A ip> zfs recv -Fuv zfs49
I tend to use -Fuv options routinely on zfs recv because:
-u confirms that I want to leave the newly-restored filesystems unmounted (for the time being) on server A. It is easy to get into trouble transfering ZFS pools from one system to another and clobbering (overlaying) existing mountpoints. The -R /mnt option on the zfs create step also protects against this, so perhaps this is a case of "suspenders and a belt," but when transfering and restoring backups, it's difficult to have too much caution.-v gives me some feedback on how the job is progressing, as each completed snapshot will be listed in turn.
As for progress indication, you may also find that zfs transfers are an excellent opportunity to make use of Andrew Wood's intrepid pipe viewer pv(1):
(From Server B:)
zfs send -R zfs49@xfer |
pv -Wbraft |
ssh <Server A ip> zfs recv -Fuv zfs49/tank
Adjust the pv options to suit your taste and needs.
Once the transfer has completed, inspect the pool on Server A, with an especially close eye to mountpoints, bearing in mind that they will be prefixed with /mnt because of your zpool create ... syntax. If you wish, you may (on Server A):
zpool export zfs49
zpool import -N zfs49
zfs list
This will import the pool to show the native mountpoints, but the zpool import -N command tells zpool to NOT actually mount anything. This is helpful to see an apples-to-apples comparison of where the pool's mountpoint will actually be located. Make sure the pool's mountpoints aren't going to overlay any existing mountpoints on Server A, or you may lose access to possibly critical filesystems. This use of zpool import -N dovetails with the above use of zpool recv -u to try to minimize the risk of mounting newly-created filesystem(s) in the wrong location(s).
Finally, once you're happy with how the pool looks on Server A, you can delete the xfer snapshot from both systems. From Server A:
zfs destroy -rv zfs49@xfer
ssh <Server B> zfs destroy -rv zfs49@xfer
One caveat that I don't have a good solution for is that it is not trivial to backup and restore properties of the pool itself, that is, options that must be read and written via zpool rather than zfs. This includes properties like bootfs, and all the other tidbits that zpool get all zfs49 shows you. Most of the defaults will likely be reasonable, and if you've changed any of them in the past, hopefully you'll recognize them and can manually change the properties on your Server A's new pool to suit your needs. Otherwise, the topic of how to backup and restore pool properties is probably worthy of a separate question, if one isn't out there already.
