How do I move some folders/files between pools and safely reduce space by removing snapshots

On Truenas 25.10.6 I’d like to move a folder1 (~3TB) from one vdev1 (Pool1-disk mirror A-16TB) which is getting full to another disk with vdev2 (Pool2-disk mirror B-12TB). I’d like to do this as quickly and safely as possible so I’ve read in the forum that I should do this from the command line. I think I’ll use rsync to move the folder1.

Both Pool1 and Pool2 have snapshots. So when I’ve finished moving the folder, I’ll have a copy on the vdev2-Pool2 and vdev1-Pool1. Once I check this, I’ll delete the vdev1 folder but I expect that it won’t release the space due to the snapshots. I’d like to make sure the moved folder frees up space on the vdev1 Pool1. The data in vdev1-Pool1 has a lot of other data in addition to the folder I’m moving.

A lot of the data in the folder has been around since the vdev1 was created a few years ago. If possible I’d like to only delete the portions of the snapshot that related to this folder1. I’m thinking this isn’t possible, but I thought I’d check. If it isn’t possible, I’m OK to delete all of snapshots for vdev1-Pool1.

So, a couple of questions.

(1) Is the logic of how I plan to move, check, delete, and remove snapshots make sense? Is there something I’m missing because I don’t know what I don’t know? I’m learning but still a newbie. :smiley:

(2) Is there a way to remove only the portion of the snapshots relating to the moved folder in vdev1? I don’t mind using the command line. If this isn’t possible, then is best practice to remove the vdev1 snapshots using the GUI? And, if I have to use the GUI, then is there some documentation on how to easily select and delete ~90+ snapshots (hourlys, dailys, weeklys, monthlys)?

Thanks in advance.

Are you using the snapshots for replication currently? When you say folder, do you mean a folder or a Dataset? Snapshots only work off Datasets. The better your details on the pool, datasets and snapshots, the better the advice from other posters.

( you should update your profile to match the TrueNAS version, if necessary)

Thanks @SmallBarky

I’m not using replication.

I mean folder. I’m looking to move /mnt/Pool1/Share/folder1 to /mnt/Pool2/FileShare/folder1. Pool1 has a one dataset and one SMB share. Pool2 has one dataset with multiple folders and multiple SMB shares.
I understand that best practice is to have a dataset for each type of media/files. Pool1 is only videos and audio files so in my mind was one type of files. Pool2 had only regular computer files and backups. Moving the folder1 (audio files) from Pool1 is going to change the media on Pool2 but I don’t know enough if it makes sense to create/add a new dataset for this new specific folder (audio) on Pool2. And not sure what adding a dataset onto the Pool2 does to the existing dataset. So I’m trying to do the easiest process for what appears, to me at least, a complicated move and clean up project.

Yes, I recently updated from 25.04 to 25.10, so I should update the profile. Should be done by the time this get’s posted.

Do you need all your current snapshots for some reason or could you delete them all and do a fresh snapshot for each pool and then move your data? Verify your data moved properly and then you can destroy those snapshots and then create new ones per your normal scheduling from there out.

If you were using replication, it would be a bit more complicated due to the snapshots being tied to any replication you were doing.

Making sure you do not need your current snapshots for history or something.

@winnielinnie What is the quick way to deal with snapshot cleanup as in the first post?

You get the full name of the oldest snapshot on the dataset.

zfs list -t snap -H -o name -s creation Pool1/Share | head -n 1

Then you use that name with % to destroy all snapshots on the dataset.

zfs destroy -n -v Pool1/Share@oldest-snapshot_2020-01-01%

I left -n for safety reasons. If you want to commit to the destruction, remove the -n flag.

There’s a way to creatively use variables and scripts, but it’s safer to do this one step at a time and confirm each step.

:warning: I recommend creating a pool checkpoint first.

zpool checkpoint Pool1

It can be discarded after you confirm everything is fine.

zpool checkpoint -d Pool1

Hi @SmallBarky

I don’t need the current snapshots as the last scrub was clean, the disks show no errors so I think I’m OK.
Thanks @winnielinnie I’ll have to do some reading on this command before I nuke too much. :blush:

Sorry for butting in, I just want to clarify something.

Snapshots do not save you if a scrub were to detect permanent ZFS errors.
A snapshot is not an additional copy of the data, so if the data is somehow corrupted, all snapshots of that data will point at that same corrupted data.

Snapshots will however save your bacon if you accidentally delete something, get hit by crypto malware, or similar.

If you need more copies of your data you would create your dataset with the copies=2 flag (or higher).

The effect this will have on the space required to store said data should be obvious.

You also need to do some reading on ZFS terminology and layout.
What you want to do is moving data between pools; you cannot move data between vdevs within the same pool anyway (but that what’s your title sounds like).

Sharing is based on datsets, so something is off here.

Not quite. Different datasets serve if you want different settings (recordsize, compression, etc.), different shares, or different snapshot policies—which may or may not be related to file type.

The question was whether you have snapshots for “folder1”. If so, replication would be the easiest way to move your data. If not, and “folder1” really is just one directory in a larger dataset, you’ll use or rsync, or plain old cp.

Nope. The content of a snapshot is immutable, that’s the whole point of snapshots.

So now could be a good time to think about your data and how you want to organise it.

Not necessarily. It’s true this is how TrueNAS defaults, but nothing prevents you from sharing a subdirectory in a dataset. OP could still be describing the setup incorrectly, of course.

Thanks @etorix . Apologies for my confusion.

I didn’t realize that if the file was OK when originally copied onto into the file share but gets corrupted at some point later, you can’t restore an old version from a snapshot prior to the corruption. Good to know.

Yes folder1 is just one directory in the Pool1 SMB share. So I think rsync is probably better than cp in case it has to be restarted.

As think about this, I guess I should turn off all snapshot jobs until the move is done. After moving and verifying/checking the files moved OK, I can delete the snapshots and then re-enable the snapshots.

Hmm. I’m getting confused.

I have /mnt/Pool2/FileShare/folderA /mnt/Pool2/FileShare/folderB /mnt/Pool2/FileShare/folderCand each is shared via SMB with one family member. The family member’s files are separate and only they can access them. The new /mnt/Pool2/FileShare/folder1 will contain moved audio files that everyone will be able to access (read, write, but not delete). All the media files were in /mnt/Pool1/FileShare/Movie /mnt/Pool1/FileShare/Audio on a separate mirrored set with SMB access to the family. Now because of the high cost of disks, I have to mix up the Pool2 and move the audio to that disk which has a lot of space.

Perhaps a strange set up but it made sense to me when I set it up years ago.

You can use ZFS replication if you have periodic snapshots.

But if you are moving everything, you can use rsync (delete the original data after the copy), or use rsync –delete-source, or even use simple mv.

The space used in the original pool will not change much as you still have snapshots.

You can delete the snapshots from the GUI, but if they are many, it would be slow, so Google for scripts to delete snapshots. You have to delete all the related snapshots in order to get that space back.

Thanks everyone.

Just a quick clarification question. When I do the rsync of the files, do I need to ssh in as “root” or can I do this using the System:Shell as “admin”? I noticed that my share shows:

drwxrwsrwt 13 1000 root 14 Jul 26 10:15 Audio

and I don’t want to get going on this and find the permissions are all wrong and the whoami shows:

$ whoami
admin

Thanks.