Hello, I have purchased a VPS because of Hetzner increased its prices. I purchased a new VPS from netcup. I will use ubuntu 24.04 on server but my current WPS running on Ubuntu 22.04.
I dont know how can I migrate my HestiaCP configs etc. May be migrating from same OS version is easier but in here two VPS has difference OS versions.
I prepared short documentation beause v-backup-user command does not solve my problem because of it’s disk control process. I will share my rebuild experience after then copying files to new server. This mention for first step: backup files migration.
This documentation outlines the step-by-step process of migrating a large user account from a source server with critically low disk space to a new target server. It leverages a custom HestiaCP backup script combined with a Network File System (NFS) mount to perform the compression and packaging directly on the destination storage, preventing local disk exhaustion.
The Disk Space Trap: Under normal circumstances, enabling Remote Backup (SFTP/FTP) via the HestiaCP Web GUI forces the server to compress and build the entire backup archive locally on the source storage first. Only after the
.tarfile is fully generated does it upload the package via Port 22. If your source disk is nearly full, the backup will immediately crash before the SFTP upload even begins.The NFS Fix: By mounting the target server’s storage via NFS, we trick the system. The source server treats the remote folder as a local hard drive. When the custom backup script runs, it bypasses the local disk entirely and streams the compressed data blocks directly across the network onto the destination hardware in real-time.
Log in to the Target Server via SSH as root. We need to install the NFS server utilities, create a temporary mount directory, and export it so the source server can connect.
# Install NFS Server utilities
apt-get update && apt-get install nfs-kernel-server -y
# Create the remote temporary folder
mkdir -p /mnt/hes_tmp
chmod 777 /mnt/hes_tmp
# Expose the directory to the network
echo "/mnt/hes_tmp *(rw,sync,no_subtree_check,no_root_squash)" >> /etc/exports
# Apply changes and restart the NFS service
exportfs -arv
systemctl restart nfs-kernel-server
Ensure the firewall on the Target Server allows incoming traffic on NFS ports from your specific source server IP.
# Allow NFS (2049) and RPCBind (111) ports for the Source Server IP
iptables -I INPUT -p tcp -s SOURCE_SERVER_IP --dport 2049 -j ACCEPT
iptables -I INPUT -p udp -s SOURCE_SERVER_IP --dport 2049 -j ACCEPT
iptables -I INPUT -p tcp -s SOURCE_SERVER_IP --dport 111 -j ACCEPT
iptables -I INPUT -p udp -s SOURCE_SERVER_IP --dport 111 -j ACCEPT
Log in to the Source Server via SSH as root. Install the NFS client and establish the network bridge to the target server’s storage.
# Install NFS Client utilities
apt-get install nfs-common -y
# Create the local mount point
mkdir -p /mnt/remote_tmp
# Mount the Target Server's temporary folder using TCP over Port 2049
mount -t nfs -o proto=tcp,port=2049 TARGET_SERVER_IP:/mnt/hes_tmp /mnt/remote_tmp
HestiaCP’s native backup script (v-backup-user) enforces a strict rule requiring free disk space equal to at least twice the user’s total data size on the local root (/) directory. To bypass this hard restriction, we isolate the process into a dedicated standalone script.
Instead of modifying core system files that could be overwritten during panel updates, create a distinct clone of the backup binary called v-backup-user-without-disk-space-control:
# Duplicate the original Hestia backup script
cp /usr/local/hestia/bin/v-backup-user /usr/local/hestia/bin/v-backup-user-without-disk-space-control
Open your newly created script using nano:
nano /usr/local/hestia/bin/v-backup-user-without-disk-space-control
Navigate down to the Action block (typically around lines 120-135) where the disk space conditional logic resides. Comment out the entire if statement block by adding a # symbol to the beginning of each line so it looks exactly like this:
# Validate available disk space (take usage * 2, due to the backup handling)
let u_disk=$(($(get_user_disk_usage) * 2))
let v_disk=$(echo "$(stat -f --format='%a*%S' $BACKUP) / 1024 / 1024" | bc)
#if [ "$u_disk" -gt "$v_disk" ]; then
# let u_disk_original=$(get_user_disk_usage)
# # Always notify on failure
# echo "Not enough disk space available ($v_disk mb) to perform the backup of $user. ( $u_disk_original mb * 2 = $u_disk mb). https://hestiacp.com/docs/server-administration/backup-restore.html" | $SENDMAIL -s "$subj" "$email" "yes"
# # Deleting task from queue
# sed -i "/v-backup-user $user /d" $HESTIA/data/queue/backup.pipe
# check_result "$E_LIMIT" "not enough disk space available ($v_disk mb) to perform the backup of $user. ( $u_disk_original mb * 2 = $u_disk mb)."
#fi
[END_CODE_BLOCK]
Save and exit (CTRL + O, Enter, CTRL + X), then make the script executable:
```bash
chmod +x /usr/local/hestia/bin/v-backup-user-without-disk-space-control
To force HestiaCP to build its temporary files entirely over the network onto the Target Server, you must inject both the TMPDIR and BACKUP_TEMP environment variables directly into the command line shell before launching the custom tool.
Run the following commands sequentially:
# Route all transient data pipelines to the NFS network share
export TMPDIR=/mnt/remote_tmp
export BACKUP_TEMP=/mnt/remote_tmp
# Execute the tailored backup sequence
v-backup-user-without-disk-space-control belcika
While the process runs on the Source Server, you can safely track its real-time progress from the destination side.
Open a terminal on the Target Server and observe the live network data expansion inside the NFS repository:
# Monitor the directory structure as temporary blocks are generated
ls -laR /mnt/hes_tmp
# Watch the live storage consumption increments every 2 seconds
watch -n 2 du -sh /mnt/hes_tmp
Once the operation concludes successfully, HestiaCP will clean up the temporary staging directory and output the definitive, uncompressed .tar package to the target destination.
After the backup is complete and the .tar file is safely moved to the /backup folder on the Target Server, you must dismantle the NFS network bridge and revert firewall entries to secure your systems.
Disconnect from the remote filesystem and delete the local mount pointer.
# Safely unmount the NFS share
umount /mnt/remote_tmp
# If the device reports busy, force unmount using: umount -f /mnt/remote_tmp
# Remove the temporary mount directory
rm -rf /mnt/remote_tmp
Remove the temporary source IP rules from your iptables matrix by using the -D (Delete) parameter.
# Delete NFS (2049) and RPCBind (111) rules for the Source Server IP
iptables -D INPUT -p tcp -s SOURCE_SERVER_IP --dport 2049 -j ACCEPT
iptables -D INPUT -p udp -s SOURCE_SERVER_IP --dport 2049 -j ACCEPT
iptables -D INPUT -p tcp -s SOURCE_SERVER_IP --dport 111 -j ACCEPT
iptables -D INPUT -p udp -s SOURCE_SERVER_IP --dport 111 -j ACCEPT
Cease the file-sharing system, update export tables, and destroy the temporary folder.
# Unexport all current network shares
exportfs -auv
# Open the exports manifest and delete the line pointing to "/mnt/hes_tmp"
nano /etc/exports
# Shut down and permanently disable the NFS and RPCBind services
systemctl stop nfs-kernel-server rpcbind
systemctl disable nfs-kernel-server rpcbind
# Wipe out the temporary folder on the target storage
rm -rf /mnt/hes_tmp