Ubuntu - create new lvm using part of previous one

I have a server in our environment that is maxed out on storage in the root partition. The request is to free up space by reallocating /home to its own partition. We have an excess of free space in /var, so I thought to remove a 20G portion of that and use it to create the new partition. The problem is I'm not exactly sure how to go about it.

Here is the output of lsblk:

NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda            8:0    0 278.5G  0 disk 
├─sda1         8:1    0     1M  0 part 
├─sda2         8:2    0     1G  0 part /boot
└─sda3         8:3    0 277.5G  0 part 
  ├─vg0-tmp  253:0    0    10G  0 lvm  /tmp
  ├─vg0-root 253:1    0    10G  0 lvm  /
  ├─vg0-opt  253:2    0     5G  0 lvm  /opt
  └─vg0-var  253:3    0 252.5G  0 lvm  /var

I expect I will need to delete /var, so the plan is to back up that data to an NFS mount we have on the server, but there is other data on the server we can't afford to lose. Furthermore, we have several servers we will need to perform this operation on, so I intend to script out the solution (and this is also why I am really looking for a solution that doesn't require rebuilding the server, even if it's a bit more complicated). I expect it would just be another lvm under sda3 called vg0-home or something.

This is the only piece of the process I'm not clear on, so after spending a couple hours sifting through extremely old similar questions, I thought I'd ask a new one. Happy to provide any additional clarifying information. Thanks!

Update showing other diagnostic info

:~$ sudo pvscan
  PV /dev/sda3   VG vg0             lvm2 [277.46 GiB / 0    free]
  Total: 1 [277.46 GiB] / in use: 1 [277.46 GiB] / in no VG: 0 [0   ]

:~$ sudo vgscan
  Found volume group "vg0" using metadata type lvm2

:~$ sudo lvscan
  ACTIVE            '/dev/vg0/tmp' [10.00 GiB] inherit
  ACTIVE            '/dev/vg0/root' [10.00 GiB] inherit
  ACTIVE            '/dev/vg0/opt' [5.00 GiB] inherit
  ACTIVE            '/dev/vg0/var' [252.46 GiB] inherit

:~$ df -Tlh
Filesystem           Type      Size  Used Avail Use% Mounted on
udev                 devtmpfs   32G     0   32G   0% /dev
tmpfs                tmpfs     6.3G  4.1M  6.3G   1% /run
/dev/mapper/vg0-root ext4      9.8G  6.4G  2.9G  70% /
tmpfs                tmpfs      32G  154M   32G   1% /dev/shm
tmpfs                tmpfs     5.0M     0  5.0M   0% /run/lock
tmpfs                tmpfs      32G     0   32G   0% /sys/fs/cgroup
/dev/mapper/vg0-var  ext4      248G   62G  173G  27% /var
/dev/mapper/vg0-opt  ext4      4.9G  2.9G  1.7G  64% /opt
/dev/mapper/vg0-tmp  ext4      9.8G  136K  9.3G   1% /tmp
/dev/sda2            ext4      974M  309M  599M  35% /boot
tmpfs                tmpfs     6.3G     0  6.3G   0% /run/user/1059
tmpfs                tmpfs     6.3G  4.0K  6.3G   1% /run/user/1023

First of all, make sure you have a backup or another recovery plan. Just in case I or you have overseen something.

As this is a special case, I could not create a "testing environment" and play it through. All is free from my mind.

First reduce "/var" to (example) 200GB using resize2fs, see man resize2fs.

I am not sure if this can be done while the device is mounted.

sudo resize2fs /dev/mapper/vg0-var 200G

Next resize the logical volume to 205G (for security give 5G extra), see man lvresize

sudo lvresize -L 205G /dev/mapper/vg0-var

Now there should be around 50G free in volume group "vg0", check with:

sudo vgdisplay vg0

As there is now still a difference between the filesystemsize and the logical volume size (200G vs 205G), you can resize the filesystem again, to fit the logical volume:

sudo resize2fs /dev/mapper/vg0-var

Summary: the filesystem must fit in the volume and the volume can not be smaller than the filesystem inside.

I thing you got the overall workflow and you can adept the numbers to your needs.

lvresize has an option --resizefs (see man lvresize) which might do all the steps in one, but I never tried this, therefore I go the long way. Maybe you can try and tell us.

Reminder: be careful, any mistake might lead to data loss.