I'm not familiar with Deja dup, but the usual method of backing up a ZFS filesystem is to snapshot it and then stream the snapshot (just a file, can be compressed) into the remote store of your choice.
The usual way is ZFS send and receive to another ZFS server. But almost no cloud storage provider supports that, other than rsync.net (and zfs.rent), which starts with $60/month. So you have to set up and manage another ZFS server with secure remote access, PIA if you ask me.
For a while now, my backup process has been essentially to run
zfs send -L -c -P "${snap}" | zstd - > "${out}"
gsutil -o GSUtil:parallel_composite_upload_threshold=150M cp "${out}" "${gcs_path}/"
Just chiming in here to say that I endorse every aspect of the answer that 7e has given you.
Snapshots are incremental, so management of your retention period is an active process and may require combining older snapshots together when you drop them.
With a zfs server on the other end you can zfs send / recv the other way to restore, and it correctly manages deleted snapshots.
They are but, unless the -i flag is specified (it isn't in my example above) then zfs send will send a complete replication stream, not an incremental.
The error occurs in transit or on client side, not necessarily on remote.
Also managing a chain of incrementals can get unwieldy.
Ask r/zfs.