Introduction
Migrating a virtual machine or container from a cloud provider to a local server can seem daunting, but with Proxmox’s powerful built-in tools, the process is surprisingly straightforward. Whether you’re looking to save on hosting costs, create a local development environment, or simply move to new hardware, this guide is for you.
We will walk through the entire end-to-end process of moving a live LXC container from a remote Proxmox server (like one from Netcup or Contabo) to a local Proxmox server (your “homelab”). Crucially, this guide also covers the most common networking and application troubleshooting steps that trip people up after the migration is complete.
Prerequisites
Two Proxmox Servers: A source server (remote) and a destination server (local).
A Running LXC Container: The container you want to migrate.
Network Access: You’ll need SSH/Shell access to both Proxmox nodes.
Let’s get started!
Step 1: Create a Full Backup of Your LXC Container
The most reliable way to move a container is to create a complete backup file. We’ll use the Stop mode to ensure a perfectly consistent, non-corrupted backup.
Log in to your source (remote) Proxmox server.
Select the LXC container you want to move.
Navigate to the Backup tab.
Click the Backup now button.
In the popup window, configure the following:
Storage: Choose a storage location. The default
localis usually fine.Mode: Change this to Stop. This will briefly shut down the container for the backup and restart it automatically when finished.
Compression: ZSTD is the modern default and offers the best speed and compression ratio.
Click Backup and wait for the “TASK OK” message in the log.
Your backup file, which will have a name like vzdump-lxc-101-....tar.zst, is now ready in the dump directory (e.g., /var/lib/vz/dump/).
Step 2: Transfer the Backup File to Your Local Server
Now we need to copy this single file to your destination server. The scp (Secure Copy Protocol) command is perfect for this.
Open the Shell for your destination (local) Proxmox server. You can do this directly from the Proxmox web interface by selecting your node and clicking
>_ Shell.Execute the following
scpcommand, replacing the placeholders with your actual details.
# Command Format:
# scp <user>@<remote_ip>:/path/to/backup/file /path/to/local/backup/directory
# Example:
scp [email protected]:/var/lib/vz/dump/vzdump-lxc-101-2025_09_04-20_51_18.tar.zst /var/lib/vz/dump/
You’ll be prompted for the remote server’s password. Wait for the file transfer to complete.
Step 3: Restore the Container on Your Local Server
Once the file is on your local server’s storage, Proxmox will automatically detect it.
On your local Proxmox server, select your
localstorage (or wherever you copied the file).Go to the Backups tab.
Select the backup file you just transferred.
Click the Restore button.
In the options window, you can set the CT ID for the new container and choose the Storage for its disk. The defaults are usually fine.
Click Restore and wait for the “TASK OK” message.
Step 4: The Crucial Part – Network Reconfiguration
Your container has been restored, but it still has its old network settings from the remote server. It will not be reachable until you fix this.
Select the newly restored container in Proxmox.
Go to the Network tab.
Double-click the network device (e.g.,
eth0).Update the following fields to match your local network:
IPv4/CIDR: Assign a new, unused static IP from your local network range (e.g.,
192.168.1.50/24).Gateway (IPv4): Enter your local router’s IP address (e.g.,
192.168.1.1).Bridge: This is critical. Ensure it’s connected to your main Proxmox bridge that has access to your physical network, which is almost always
vmbr0.
Click OK.
Step 5: Troubleshooting – “This Site Can’t Be Reached”
You’ve done everything right, but you still can’t access your application (like ERPNext). This is where most people get stuck. Let’s diagnose it.
Diagnosis 1: Can the Network See the Container?
First, check for basic connectivity. From your own PC (not the Proxmox shell), open a terminal or Command Prompt and run a ping command.
ping 192.168.1.50
If you get “Destination host unreachable”: Your problem is in Step 4. Double-check the container’s IP, Gateway, and especially that it’s connected to the correct Bridge (
vmbr0). Also, temporarily disable the Proxmox firewall at the Datacenter and Node level to rule it out.If you get a successful reply: Great! The network layer is working. The problem is with the application itself.
Diagnosis 2: Is the Application Even Running?
If the ping works but your browser says “Connection refused,” it often means the application service inside the container didn’t start.
Open the container’s Console or Shell from the Proxmox UI.
Use the
ss -tulpncommand to see all listening services. We’ll filter for our app’s port (e.g.,8000for ERPNext).
ss -tulpn | grep 8000
If this command returns no output, you’ve found the problem! The service is not running.
Diagnosis 3: Starting the Application Manually
To fix this, you need to start the service. But first, you need to find its installation directory and the correct user.
Use the
findcommand to locate the application’s main directory. For ERPNext, we search forfrappe-bench.
find / -type d -name "frappe-bench"
# Example Output: /home/waqas/frappe-bench
This output tells us the user is waqas and the directory is /home/waqas/frappe-bench.
Now, switch to that user, navigate to the directory, and start the service.
# Switch to the correct user
su waqas
# Change to the application directory
cd /home/waqas/frappe-bench
# Start the service (for ERPNext)
bench serve --port 8000
Note: Some older versions of bench do not use the --host flag. If the above command fails, try bench serve --port 8000 instead.
After running this, your application should be accessible in your browser!
Step 6: Making the Service Permanent
The bench serve command is temporary. To ensure your application starts automatically after a reboot, you need to set up its production services.
# Switch to the user and go to the directory as before
su waqas
cd /home/waqas/frappe-bench
# Run the production setup command
bench setup production waqas
This command will configure systemd to manage your application, making it a robust, auto-starting service.
Conclusion
Congratulations! You have successfully migrated an LXC container, reconfigured its network for a new environment, and troubleshooted common application-level issues. This process gives you the freedom to move workloads between providers and your own hardware with confidence.
