SOLVED Lost Access to Dataset

[ere109]

I purchased some larger drives to move one of my pools, then used zfs snapshot and send to move the contents to the new drive pool. It took several hours for the operation to complete - 1.1 gb transferred. In the GUI, I can see that the dataset on the new pool is 1.22gb. However, I can't see any files in CLI. This is a list of the commands I sent, and the steps I've taken.

sudo zfs snapshot -r MEDIA/A@2023-02-06_snapshot sudo zfs send -Rvn MEDIA/A@2023-02-06_snapshot sudo zfs send -Rv MEDIA/A@2023-02-06_snapshot | sudo zfs receive -d -v ET sudo zfs destroy -v MEDIA/A@2023-02-06_snapshot
The affected folder was "mine," and I've chown'd it to root, and run chmod -R 777, but it still shows 0 files.
Any thoughts?

 

[Arwen]

Please supply the output of the following commands, in code tags. This will give us more information to help you.
zfs list -t all -r ET zfs get mountpoint

The probable cause is that the copied dataset, "MEDIA/A", does not have a mount point on "ET" or is not mounted.

 

[ere109]

Thanks. I think we're both onto the same thing. I just read an article that said the snapshot could "hide" the files within itself. Maybe it's a matter of restoring from the snap. The funny thing is, the "Media" snapshot worked flawlessly. It was just the second "A" one that didn't. Perhaps I just need to send the snap again.
NAME USED AVAIL REFER MOUNTPOINT ET 12.8T 24.7T 185K /mnt/ET ET/Media 11.6T 24.7T 11.6T /mnt/ET/Media ET/Media@2023-02-05_snapshot 0B - 11.6T - ET/A 1.22T 24.7T 199K /mnt/ET/A ET/A@2021-03-31_snap 1.22T - 1.22T - ET/A@2023-02-05_snapshot 99.4K - 199K -

Beginners Guide to ZFS Snapshots

This guide is intended to show a new user the capabilities of the ZFS snapshots feature. It describes the steps necessary to set up a ZFS filesystem and the use of snapshots including how to create them, use them for backup and restore purposes, and how to migrate them between systems.

www.thegeeksearch.com

I think the above solves it, but as requested: I've got a lot going on, within my system, so I pulled non-relevant info about other pools.
NAME PROPERTY VALUE SOURCE CAMS mountpoint /mnt/CAMS default DOWN mountpoint /mnt/DOWN default DOWN/Torrents mountpoint /mnt/DOWN/Torrents default ET mountpoint /mnt/ET default ET/Media mountpoint /mnt/ET/Media default ET/Media@2023-02-05_snapshot mountpoint - - ET/A mountpoint /mnt/ET/A default ET/A@2021-03-31_snap mountpoint - - ET/A@2023-02-05_snapshot mountpoint - - MEDIA mountpoint /mnt/MEDIA default MEDIA/Media mountpoint /mnt/MEDIA/Media default MEDIA/A mountpoint /mnt/MEDIA/A default MEDIA/A@2021-03-31_snap mountpoint -

 

[ere109]

I'll be a patient man, but I suspect it's a matter of sending and receiving the snapshot again. The error may have been caused because I used the same snapshot name for both "Media" and "A". It's also strange to me that - without prompting - it copied a 2021 snapshot. Maybe that was the last time I added data to that folder?
Last question, once the data is re-sent/received, will it be safe to delete the snapshots?
Reading this:
Snapshots are saved in a hidden .zfs folder for each dataset. Note that the .zfs folder won't be listed by ls -a, but it is there.

Deleting snapshots

Quick question: I want to delete ALL SNAPSHOTS and start over from scratch (not the data, the snapshots). Reason: My previous periodic snapshot tasks were messy, had a life that was too long, were too frequent etc. I'm been trying to research the question but I can't find a definitive answer...

www.truenas.com

 

[Arwen]

Looks like you copied the ZFS datasets A & Media just fine. They are probably not mounted. Use df -h to verify that is the case.


In someways, you should not be performing this task test on live data. Create a test VM with several small virtual hard drives and install TrueNAS Core. Then perform the tests their. No need for Mirroring or RAID-Zx of the data, simple single disk pools should be fine.

When you think you have the commands working, write a "recipe" file. (A plain text help file on ZFS, which in this case describes how to copy a pool and or single dataset.) Then run through the "recipe" on your VM again, just to verify you wrote the sequence down correctly.

In regards to the question about the snapshots. Yes, you can destroy the snapshots, on both source pool and destination pool after a successful ZFS Send & Receive. However, their are reasons to keep these snapshots, if you intend incremental ZFS Sends in the future.


While I really like ZFS, it has some gotchas which you can loose data. People have worked on the wrong pool or dataset, and then really wanted an un-delete function.

 

[ere109]

Thanks for all of your help, @Arwen. I've been creating my own personal set of ~man pages, in little .txt files, for several years, now, and this will go in the pile with my notes on rsync, tmux, jail installs, etc. The biggest clue to the puzzle was zfs list; seeing those large snapshots hiding in the background lit the path to my solution.
Because the directory had already been created, I had to
rm -d the dataset, and then I edited my send/receive script to point to the older snapshot.
sudo zfs send -Rv MEDIA/A@2021-03-31_snap | sudo zfs receive -d -v ET
That solved the problem. Finally, I executed sudo zfs destroy -v ET/A@2021-03-31_snap to remove the now-empty snapshot. Had the second copy been the only one, I'm sure there would have been a way to extract from that, but this re-created my entire structure and all files. Problem solved. Thank you again.

 

[Arwen]

Great, glad it was straight forward with the new information.

If / when you get a chance, please mark this thread Solved.

 

[ere109]

For future reference, where is the "solved" button?

 

[Arwen]

Looks like you found it.

But for others, it is in the 3 dots with down arrow, at the top of the postings. Edit the thread. Then change the "(No prefix)" to SOLVED.