Bought new disks, any simple way to migrate the pool?

[Octopuss]

I tried searching around, but couldn't find anything I would consider simple enough. I am particularly lazy today though and didn't spend too much time going through the results I admit.
What I currently have is a pool consisting of 3x4TB HDDs.
What I bought are 4x1,92TB SSDs.
I just want to migrate the pool to the SSDs without having to create a new pool and configuring everything from scratch.

Is there a simple way to do this?

 

[Davvo]

No since they are smaller than the existing pool.
Maybe, and I say maybe, you can zfs send zfs receive the datasets.

 

[Etorix]

This post seems relevant…

SOLVED - Need help, but don't tell me what to do

Hi all, I've been having some problems with a NAS I built for myself years ago out of junk parts and I want to know if you all can help me to figure out why it's not faster than my friend's NAS... I think it might be running TrueNAS SCALE. Before anyone asks, "I've pressed all the buttons...

www.truenas.com

You can't replace 4 TB drives by smaller 1.92 TB drives.
You can't move from a likely 3-wide raidz1 vdev to any 4 drive layout.

Create a new pool with the new drives and replicate data from old pool to new pool.

 

[Octopuss]

So there is no way to copy the pool settings, permissions and whatnot? I forgot all I learned when I was setting this up, and vaguely remember it was pure hell getting it to work with SMB shares etc.

 

[Davvo]

Just create another pool and manually copy the settings you have in the other.

 

[sretalla]

So there is no way to copy the pool settings, permissions and whatnot?

if you use zfs replication or send | recv, permissions and other properties of the datasets will transfer across.

Share settings are stored in the config, so to have those "transfer" you need to do a switch-around on your pool names after the transfer.

See here (yes, the theory applies to moving to a smaller pool too):

Howto: migrate data from one pool to a bigger pool

There have been a lot of posts recently about how to move data from one pool to another. Usually it's because folks want to upgrade to a much larger pool and the drive-by-drive resilvering process will take too long. I've recently gone through this as well. Here are the steps that I followed...

www.truenas.com

 

[Octopuss]

Agh, looks like I will have to redo everything from scratch, because I can't connect both the old and new disks at the same time. I need to replace the HBA too, and they have different cables.
Do I understand correctly the NAS settings are stored on the disks themselves instead of the VM (I have the system virtualized), so if I remove the pool, everything is lost?

 

[sretalla]

Do I understand correctly the NAS settings are stored on the disks themselves instead of the VM (I have the system virtualized), so if I remove the pool, everything is lost?

Config (Users, groups, shares, network, other system settings) and Pool data (including Datasets and ZVOLs together with their data/content and ACLs) are separate things.

Your config helps the system remember which pools are mounted at startup, but that's the only hard link between the two things.

The boot pool hosts the config (which can also easily be backed up from System | General) and the data pool does what's written on the box (holds the pool data).

 

[Octopuss]

Ah ok, thanks. I had a vague memory of the settings being somewhat complicated, this was it I guess.

So if I can only have each set of the disks "active" at once, is it at least possible to do a snapshot of the pool of some sort, copy the actual data to another disk, then replace the disks, create a new pool and import the settigs of the old one and copy the data back with the original permissions?

 

[sretalla]

So if I can only have each set of the disks "active" at once, is it at least possible to do a snapshot of the pool of some sort, copy the actual data to another disk, then replace the disks, create a new pool and import the settigs of the old one and copy the data back with the original permissions?

Following the process I linked above (in this case, you'll need to do it twice) will work.

You get a full copy of the pool at each send | recv completion (which does use snapshots, although I guess you don't fully understand what snapshots are the way you asked that).

 

[Octopuss]

No I don't, sorry.
Also send/recv sounds like a copy operation, but I can't have two pools running at the same time, because I can't connect both sets of disks at the same time. Sorry I know nothing about Linux.

 

[sretalla]

zfs send (which then gets piped to zfs recv) is a way to transfer ZFS datasets or ZVOLs between pools (or even to the same pool) using snapshots.

Take a snapshot of your dataset (recursive if you want)... that just takes a separate list of all the blocks used on the disk(s) to make up the targeted dataset/ZVOL(s).

zfs send that snapshot to the target (specified with zfs recv... need to make sure the send is also recursive if the snapshot was)

then both sides have the exact same data. And because you were working with a snapshot, the operation isn't impacted if something changed on the original source while it was in progress.

As you said, if you provide a temporary disk (must be made into a pool) to copy the data to, then you can do that process once to the temporary disk, then again to the new pool.

You haven't mentioned the version you're using, but only SCALE is Linux... CORE is FreeBSD Unix.

 

[Octopuss]

Ah ok, that sounds a little clearer. I'm sure I'll mess it up and give up, but it's worth a try.

 

[Octopuss]

Ok so first stop before I even started (that was so unexpected).
The above linked thread is clearly meant for advanced users and I am missing several steps it seems.
I guess I need to connect a new disk to the existing setup and create a pool on it, but what settings do I need to give it?

 

[joeschmuck]

If you are replacing the 3x4TB drives with 4x2TB drives, it doesn't sound like you have a lot of data.

With that said, you have said you are virtualizing this and while I have no idea your hardware setup, would it be possible to connect all the drives to the physical machine and boot from a TrueNAS USB flash drive? Note that the drives can be connected to any HBA/SATA port, it does not matter at this point in time as all you need to do is make the drives visible to TrueNAS. Then restore your configuration file and setup your NIC from the console. Now you should have all your drives available and you could perform the operation suggested. Since you don't apparently have a lot of data, it shouldn't take too long.

Just thinking outside the box you are in.

 

[Octopuss]

That idea only makes me even more horrified
Not saying it's not possible, but right now I am scared shitless and frustrated to no end, because I clearly hit a hard limit of my extremely basic "set it up and for F**K's sake don't touch it ever again" knowledge of all this.

The main problem is that I am a life long Windows user, where I would say I am on the advanced level of knowledge. All of this however, I feel like a complete retard. I don't really need to touch anything about the server, because fortunately it works pretty well, and everytime I need to change something somewhere, I am starting from scratch. Even the extremely basic things. I just know absolutely zero about Linux, the command line and the concepts, and it's so alien to me I just can't memorize even the most simple things. Obviously, not having to work with this makes it even worse.

One day I had it with the damn Synology NAS box that was a complete pain in the ass, and also with the cable mess around the router and switch, and started thinking about an all in one box, and came up with a small rack with a big fat UPS, managed switch, and a server sitting on top of it that runs ESXi and VMs with pfSense and TrueNAS. All this took me weeks to set up, and once it was working I quickly managed to forget everything I learned in the process.
I know I am exactly NOT the guy who should have done this, but I'm past that point, heh.

So unfortunately while I do understand the general concept how what I'm trying to achieve here is done, the specifics in the damn command line and the other things completely and utterly escape me.

 

[joeschmuck]

I am a life long Windows user, where I would say I am on the advanced level of knowledge.

You got me beat. I'm 60 years of age, started programming in machine code (Hex). Went through Windoze (version 1.0 to 11). I'm not a system admin type but I can easily get myself into trouble. I do my research, Google is my friend. And I'm not a Linux person either, but I'm learning parts of it as I go. I actually like Linux Ubuntu Cinnamon which is very Windows like. I have it in a VM so I can play with it periodically. But it's not Windoze as I cannot install Windoze programs on it. A downside I guess.

I quite frequently will start all over from scratch as I see it as another learning opportunity, and I do learn. Just backup all your data before you start anything. You will learn and relearn about permissions, which is actually the most difficult thing I think. Myself, since I'm not exposing my LAN to the WAN, I open up all the permissions (chmod 777). While my wife or daughter could do some damage, they do not because they do not access my NAS, not at all. They have no idea how to nor do they care. But in a home where you have little devils trying to do things because it's there, well permissions are a must.

small rack with a big fat UPS, managed switch, and a server sitting on top of it that runs ESXi and VMs with pfSense and TrueNAS

You shot yourself in the foot if you didn't keep up with the system. Hopefully you have been updating ESXi with the security updates. pfSense should be updating itself if you set it up correctly. TrueNAS really doesn't need much but you do need to have it configured correctly so you get notifications.

I too ran pfSense and TrueNAS in ESXi a long time ago. I no longer need pfSense, my Router takes care of this now (third party software) and I'm happier this way.

Something I did when I first started using FreeNAS, I created a single sheet of paper that contained the exact step by step instructions on how to replace a failing hard drive. At the time it seemed like a complicated task, until I typed it up myself. I placed that piece of paper inside the computer case where it remained and was never used. I made this procedure for my peace of mind and so I could replace a drive if ever needed without doing any research. I learned from it. I'm just saying, learn from your pending work. Write up a small list of instructions on how you created the NAS, configured the TrueNAS GUI, file permissions, etc. You will learn and if you need to reflect on something 2 years down the road, you will have it.

Best of luck to you.

 

[Octopuss]

The problem is I can do most of the very basic things in the GUI, but the moment I have to touch the command line I am completely lost, because this ecosystem is a complete klingon to me. In fact, I think I would have easier time learning klingon than this.

 

[joeschmuck]

That is funny, very funny. "tlhIngan jIH" (just a little Klingon for you)

Here is something you could do... When you are about to enter a CLI command, do a Google search for the command and "manual freebsd" for FreeNAS/TrueNAS Core, or if you are going to use Scale "manual debian". This will give you some information about the command, the options for the command, and sometime examples. For example "zpool import manual freebsd". I used it yesterday, not for myself but before I provided some advice. I wanted to ensure I got my facts correct before saying anything. Like you, I'm not a guru on this stuff. I find it very helpful.

 

[ChrisRJ]

The problem is I can do most of the very basic things in the GUI, but the moment I have to touch the command line I am completely lost, because this ecosystem is a complete klingon to me.

I am wondering for what exactly you had to use the command line. In more than 10 years of FreeNAS/TrueNAS I never had to use the command line for anything but check log files and run custom scripts.