But now to my version, even if it is quite banal.
Note:
The information is without guarantee. It works for me, but something may have been changed during translation
For reasons of laziness, I like to do this using variables and command chains.
And I start with "
sudo su
", so be careful!
My variables are e.g. (more will come later)
The NETH8 partition
ORIG_PART=sdb1
the name for the previous NETH8 paths (used for the comment in /etc/fstab and the mount point)
NETH_MOUNT=neth8_root
Create a mount point for the previous NETH8 paths
mkdir /mnt/${NETH_MOUNT}
First, I mount the boot drive (with the NETH8 base path) in another path - this way I still have access to the paths that will later be “overmounted”.
mount alternative mount points for originals in /etc/fstab
echo “# Alternative mount point for NETH8 PATHS ${ORIG_PART}” | sudo tee -a /etc/fstab
echo “$(cat /etc/fstab | grep -A 1 ${ORIG_PART} | grep “UUID” | sed “s|/|/mnt/${NETH_MOUNT}|”)” | sudo tee -a /etc/fstab
View fstab
cat /etc/fstab
mount the new mount points without rebooting
this is harmless because no existing mounts have been changed
systemctl daemon-reload
mount -a
check mounting with:
findmnt -t none -o TARGET,SOURCE,FSTYPE,PROPAGATION
Is there anything to see?
ls -al /mnt/${NETH_MOUNT}
prepare new disk. I don’t like to explain this here, too much can go wrong. I’m sure you know this yourself anyway (like most people here, but maybe it will help someone)
my new disk
NEW_DISK=sdc
the partition on my new disk
PART=${NEW_DISK}1
permanently mount the new disk in /etc/fstab:
echo “# Own mount point for PARTITION /mnt/${PART}” | sudo tee -a /etc/fstab
echo “UUID=$(blkid /dev/${PART} | awk -F’"’ ‘{print $2}’) /mnt/${PART} ext4 defaults 0 2” | sudo tee -a /etc/fstab
view fstab
cat /etc/fstab
mount the new mount points without rebooting. this is harmless because no existing mounts have been changed
systemctl daemon-reload
mount -a
check the mount with:
findmnt -t none -o TARGET,SOURCE,FSTYPE,PROPAGATION | grep ${PART} | sed ‘s/ */ /g’
Is there anything to see?
ls -al /mnt/${PART}
My drives and mounts are therefore primarily under /mnt/, and they stay there. This way I don’t lose track of things and I can easily exclude this path for rsync backups (I don’t want everything twice). The mount bind to the NETH8 paths will only be done later.
Now we can transfer the data. I would prefer to stop the container here, without stopping you have to prevent users from using it in some other way
I would like to transfer the following data / paths
Path to the desired folder in the samba1 container
SOURCE=/home/samba1/.local/share/containers/storage/volumes
Define destination for the container data (new disk)
TARGET=/mnt/${PART}
Create complete path for container data - Preview
echo ${TARGET}${SOURCE}
Note: The entire path to the target folder on the additional drive is created here. It basically corresponds to the original path. This keeps the option open to include other folders on the same drive in the same path. For example, the user folders or certain shares. Or other container volumes. In the example, however, I have “everything”.
mkdir -p ${TARGET}${SOURCE}
the folders obviously do not have the correct permissions. This should be corrected with the following “rsync” of the files (I think)
Sync source files in path and adopt permissions
rsync -a $SOURCE/* ${TARGET}${SOURCE}
take a look
ls- al ${TARGET}${SOURCE}
now it’s getting exciting. If everything is there, you could mount the bind mounts temporarily (not reboot-proof)
Mount bind mounts temporarily
mount --bind ${TARGET}${SOURCE} $SOURCE
or mount them in /etc/fstab so they are reboot-proof
Mount bind mount permanently in /etc/fstab:
echo “# Own bind mount for CONTAINER DATA ${TARGET}” | sudo tee -a /etc/fstab
echo “${TARGET}${SOURCE} $SOURCE none bind 0 0” | sudo tee -a /etc/fstab
view fstab
cat /etc/fstab
mount mountpoints without restart
systemctl daemon-reload
mount -a
check integration with:
findmnt -t none -o TARGET,SOURCE,FSTYPE,PROPAGATION | grep $SOURCE | sed ‘s/ */ /g’
in my attempts, integration into the containers worked directly, but without stopping/starting the affected containers, I would recommend a restart.
This is my approach, for a trial comparison for all others who are there
regards
yummiweb
This would have triggered a new installation by the doctors software providers, a 10K “problem” for me and my clients…