We're running a Xibo signage installation inside Docker Desktop on a Windows VM. That VM will soon be replaced with a Proxmox VM, preferably running Ubuntu or another Linux distribution. I need to migrate the existing installation and its data without rebuilding everything from scratch, but I didn't configure the original setup and I'm not very familiar with Docker Desktop. What should I back up, and what is the safest way to restore it on the new Linux host?
4 Answers
For Xibo, pay particular attention to its MySQL database and CMS library. Export the database with mysqldump while the database is running, then restore that dump into a new MySQL container. Copy the CMS library volume separately, for example with rsync or an archive. Avoid copying a live InnoDB data directory while MySQL is writing to it, since that can produce a corrupt or unstartable restore.
You generally don’t back up the container itself. Containers are disposable; the important pieces are the Docker Compose file or equivalent configuration, the image versions, environment variables, and every named volume or bind-mounted directory used by the application. Recreate the containers on Linux with the same configuration, then restore the persistent data into the corresponding volumes.
I didn’t set up the original installation, so I’ll first need to identify the Compose configuration and which volumes or host directories it uses before moving anything.
Start by inspecting the existing setup with Docker Desktop or commands such as docker compose config and docker inspect. Record the image names and tags, environment settings, port mappings, networks, volume mounts, and restart settings. On the Linux VM, install Docker and Compose, recreate the directory structure, restore the volumes or bind-mounted files, import the database backup, and run docker compose up -d. Test the signage application before retiring the Windows VM.
A blanket tar archive of a containers directory is risky and may include temporary files, configuration you don’t need, or an inconsistent database. Stop the application before copying ordinary file-based volumes, but use a proper database dump for MySQL. Keep the original Windows VM intact until the Linux instance has been fully tested and confirmed to contain all schedules, media, users, and settings.
That clears things up. I’ll treat the database and the CMS files separately instead of trying to archive the running containers.