Help - Move jail root

[sandra]

I'd like to move my jail root which resides in: /mnt/system/jails on a SSD (which does not support the TRIM command and creates thousands of error messages while FN tries to TRIM it and therefore will go in the garbage).

My anticipated process:
- stop all jails
- create a new temporary volume/dataset (I want to swap the SSD out to a new one)
- copy -using a root/cmdline- the whole old jail root to the temporary created dataset
- replace SSD
- create volume/dataset on the new SSD (system/jails mount to /mnt/system/jails, same as the old mount point)
- copy the jail root back to the new SSD
- start jails services

Will this work? Any reboot recommended during the process?

P.S.
Why not re-installing the whole jail root, well, big download and MiniDLNA manual configuration took an hour...

 

[DrKK]

I would suggest the following:

1. Stop all jails
2. Take a recursive snapshot at the root of the jail, right in the GUI, call it "jailxfer" or something.
3. Use ZFS send to send the entire jail pool snapshot to a convenient file on the main storage pool. It might look something like this:
   Code:

   zfs send -r jails@jailxfer > /mnt/mainpool/jailxfer.zfs

   . This will create a file that contains the "full recursive stream" of that ZFS dataset and its descendants.
4. Detach the old SSD, and remove the device.
5. Replace with the new device.
6. Use the volume manager to format the new SSD
7. Use the "zfs recv" (or "zfs receive", same thing) command on the jailxfer.zfs file to restore that dataset on the new ssd. INstructions for this are on the same link as in step 3.
8. Go back into jails->config in the GUI, and set the jail root appropriately
9. Turn jails back on.
10. If everything looks OK, use the GUI to delete the "jailxfer" snapshots and its descendants.

That is the "correct" way. The way you were proposing, a mass "copy" operation, is just begging for some kind of issue with locked files or permissions or something.

 

[sandra]

TY, will report success ASA the new SSD arrives...

-s-

 

[DrKK]

I guess in principle, if you remove the original ssd, the snapshot of it would presumably be removed as well.

What you would remove, then, would be that jailxfer.zfs file, once you're convinced you're in good shape.

 

[Jurgen Segaert]

I believe there's a step (7.5) missing in DrKK's procedure, where it updates the jail root mount point in warden.
Here's a link to another relocate jails How-To that has this additional step.

 

[DrKK]

I believe there's a step (7.5) missing in DrKK's procedure, where it updates the jail root mount point in warden.
Here's a link to another relocate jails How-To that has this additional step.

That's possible; I never had to do that myself because when I swapped out my SSD for a new one for the jails pool, I named it the same. So I guess that worked out.

Thank you for the input.

 

[DrKK]

That's possible; I never had to do that myself because when I swapped out my SSD for a new one for the jails pool, I named it the same. So I guess that worked out.

Thank you for the input.

Of course, if the GUI doesn't automatically update the warden to reflect what you put in the JAILS->CONFIG screen, that would be bug-like behavior in my view. Are you sure it's necessary?

 

[sandra]

That's possible; I never had to do that myself because when I swapped out my SSD for a new one for the jails pool, I named it the same. So I guess that worked out.

Thank you for the input.

That is the plan, using the same name. Since the original SDD/pool has been removed, there's no name-conflict when receiving the backup.

 

[Jurgen Segaert]

That's possible; I never had to do that myself because when I swapped out my SSD for a new one for the jails pool, I named it the same. So I guess that worked out.

Yes, since the OP will also stick to the same name, things should be fine. :)

I've never tried to move the jails folder to a different pool/name either, so I cannot confirm that the additional statement in the thread referenced above would still needed, or if the GUI now takes care of this automatically. In case it doesn't, and somebody needs this in the future, the possible solution is hereby documented.