I'm wondering if there is someway to reset the zfs snapshots without deleting a dataset. 

I have 3 zfs drives, 1 cache and 1 unassigned devices and both of them are replicating to a ZFS drive in my array using 2 copies of spaceinvaderone's script. 

 

But i think my unassigned drive which is my plex appdata somehow didn't actually get a full snapshot, even though it says it did.

really hard to explain what I mean but ill do my best. 
Here is my ZFS master

 

My appdata folder from cache seems to be working fine and everything is backed up to the zfs-backup on disk9 with no issues
But my binhex-plexpass does not seem to be actually backing up to the zfs-backup-plex, The snapshots say they are getting incrementally backed up but no data is being populated on plex_appdata_binhex-plexpass like it is on cache_appdata

Example when i browse cache_appdata i see files

But if i browse plex_appdata_binhex-plexpass its empty, like it never got the first full snapshot


So im just not sure what I need to do to fix it or even if there is a way to without blowing away the plex_appdata drive and rebuilding again, which i really dont want to do. its something like 420GB of plex appdata which takes a long time to build.

 

Sanity check: In theory if I deleted all the snapshots from both datasets binhex-plexpass and plex_appdata_binhex-plexpass. Then took a snapshot, shouldn't it send a full backup from binhex-plexpass -> plex_appdata_binhex-plexpass when the Spaceinvadeone script runs?

Posting how i fixed this just in case someone else runs into this. 

So I still never figured out what exactly the issue was but I ended up backing up binhex-plexpass using the old Backup/Restore Appdata plugin again. Then reformatted plex_appdata as xfs, then again back to zfs (I tried zfs first but it didnt fix the issue, so i had to do xfs first then zfs again). Once I did that I restored from the Backup/Restore Appdata plugin and the ran the spaceinvaderone script and it did a proper full snapshot... what a headache with no clear reason why.