How to Restore Multiple MySQL Versions Using Docker and Azure

Manage multi-version MySQL restores easily using Docker and Azure. Build reliable restore workflows with guidance from our MySQL Support team.

How to Restore Multiple MySQL Versions Using Docker and Azure

Managing database restores becomes complex when different servers run different MySQL versions. Shared hosting environments often face this challenge because customer applications depend on specific database setups. Handling backups and restores across these versions can create compatibility issues and increase operational complexity.

This article discusses the challenges of multi-version MySQL restores and explains how Azure can be used as an intermediate restore platform. It also explores how Docker containers allow teams to run multiple MySQL versions safely on a single system and simplify the restore process. Read the article to understand how this approach makes database restores easier and more reliable.

 

Why Multi-Version MySQL Restores Are Hard to Manage

In the majority of shared hosting companies, different servers operate various MySQL versions because customer applications depend on specific database setups.

This is an example of a common setting.

• Server A runs MySQL 5.5
• Server B runs MySQL 5.6
• Server C runs MySQL 5.7
• Server D runs MySQL 8.0

R1Soft is typically used to take backups, which are then kept on a central backup server. Most of the time, the restore works without problems. But problems continue to arise. Metadata may become corrupted, backups may be partial, or customers may request raw database dumps.

Engineers have to manually restore the database when this occurs.

At this point, another challenge emerges. The original server’s MySQL version must be used by the restoration server. Teams frequently attempt to install multiple MySQL versions on a single system as a result. So, they run into problems such as

• Conflicting binaries
• Port clashes
• Dependency issues
• Risk of breaking existing installations
• Difficult maintenance

These problems make managing the restore setup challenging. Additionally, when databases come from dozens of servers running various MySQL versions, this method does not scale effectively.

Why Azure Works Well as an Intermediate Restore Platform

Instead of relying on a single on-premises restore server, many teams use Microsoft Azure as an intermediate restore platform. Azure provides a flexible cloud environment where restore systems can be created only when needed. This makes it easier to handle restores from multiple servers and different database versions.

Here are the main reasons teams choose Azure.

• On-demand compute

Engineers can start a Linux virtual machine only when a restore is required and remove it after the task is finished. This avoids running a permanent restore server.

• Predictable performance

Azure offers different virtual machine sizes, so teams can choose the right resources based on the restore workload.

• Centralized storage

Database dumps, such as .sql files, can be stored in Azure Blob Storage. This allows restore environments to access backup files from a single place.

• Better isolation

Each restore can run in a clean and temporary environment. This prevents conflicts and allows teams to use specific database versions safely.

• Automation support

Teams can trigger restore workflows automatically using Azure Functions and Logic Apps, which helps them build fully automated restore pipelines.

• Backup and disaster recovery support

Azure provides tools such as Azure Site Recovery that help replicate systems and enable quick recovery when failures happen.

• Cost efficiency and security

Azure follows a pay-as-you-use model and also provides strong security features, encryption, and compliance support.

Because of these capabilities, Azure works well as an intermediate restore platform where teams can perform database restores in a reliable and scalable way.

Docker Solves the Multi-Version MySQL Problem

Running several MySQL versions on one server often causes conflicts and makes the system hard to manage. Docker helps solve this by allowing each MySQL version to run in its own container.

Instead of installing many MySQL versions on the main server, teams can run them in separate containers. As a result, each version stays isolated and does not affect the others. This makes database restores safer and easier.

Docker works well for multi-version restores because

• Each MySQL version runs in its own container
• No conflicts between versions
• Containers can start or stop quickly
• MySQL does not need to be installed on the host server
• A clean environment for testing and restoring

Because of this setup, teams can restore databases from MySQL 5.5, 5.6, 5.7, and 8.0 on the same virtual machine without breaking the system.

Architecture Overview

The restore setup follows a simple flow where each step handles part of the recovery process.

Initially, backups are kept in Azure Blob Storage and originate from the R1Soft backup server. The restore procedure is then carried out using an Azure Linux virtual machine. The necessary MySQL versions are run in Docker containers on this machine, and the database dump is restored within the appropriate container.

• Azure Linux virtual machine

Engineers complete the restore procedure in the Linux virtual computer, which serves as the restore environment.

• Docker containers

Docker containers allow different MySQL versions to run on the same machine without conflicts.

• Azure Blob Storage

The SQL dump files from the backup system are kept in Azure Blob Storage for access during the restore.

• Optional automation

Containers can be established, and restoration procedures can be carried out automatically by scripts or Azure Functions, which reduces manual work.

Step-by-Step Running Multiple MySQL Versions on Azure

This setup uses an Azure Linux virtual machine and Docker containers. Each container runs a different MySQL version, which allows engineers to restore databases safely.

1. Create an Azure Linux Virtual Machine

First, create a resource group and a virtual machine.

az group create --name restore-rg --location eastus

az vm create \

--resource-group restore-rg \

--name mysql-restore-vm \

--image Ubuntu2204 \

--admin-username azureuser \

--generate-ssh-keys

Next, connect to the machine and install Docker.

sudo apt update

sudo apt install docker.io -y

sudo systemctl enable docker

sudo systemctl start docker

2. Run Different MySQL Versions in Containers

Now start separate containers for each MySQL version.

MySQL 5.6

docker run -d \

--name mysql56 \

-e MYSQL_ROOT_PASSWORD=pass \

-p 3307:3306 \

mysql:5.6

MySQL 5.7

docker run -d \

--name mysql57 \

-e MYSQL_ROOT_PASSWORD=pass \

-p 3308:3306 \

mysql:5.7

MySQL 8.0

docker run -d \

--name mysql80 \

-e MYSQL_ROOT_PASSWORD=pass \

-p 3309:3306 \

mysql:8.0

Each container runs independently, so different versions do not interfere with each other.

3. Restore the Database Dump

Upload the SQL dump file to the virtual machine or download it from Blob Storage.

Then import the backup into the required container.

docker exec -i mysql57 mysql -u root -ppass < backup.sql

At this stage, engineers can

• Check tables
• Fix collation problems
• Repair damaged tables
• Clean the database before export

4. Export the Clean Database

After validation, export a fresh database dump.

docker exec mysql57 mysqldump -u root -ppass dbname > restored.sql

The restored dump can then be uploaded back to storage or delivered to the customer.

Benefits of This Azure and Docker Workflow

Using Azure together with Docker makes database restores easier to manage. Azure provides the infrastructure, while Docker runs each MySQL version inside its own container. This setup helps teams avoid many problems that usually happen during restores.

Consistent environments

Docker packages the application and its required components together. Because of this, the setup behaves the same in development, testing, and production.

Portable and flexible

Containers can run on different systems such as local machines, on-premises servers, or cloud environments.

Supports automated workflows

The setup works with tools like Azure DevOps or GitHub Actions. Teams can automate build, test, and deployment steps.

Scalable and efficient

Containers start quickly and use fewer resources than full virtual machines. This helps teams handle changing workloads.

Simple management

Azure services reduce the need to manage infrastructure manually, so engineers can focus on restore tasks.

Better security

Azure provides access control, private container registries, and image scanning to protect systems.

Cost control

Teams pay only for the compute and storage they use, which helps reduce unnecessary costs.

No version conflicts

Each MySQL version runs in its own container, so different versions do not affect each other.

Faster restores

Containers start within seconds, which allows engineers to begin restoring work quickly.

Clean restore environments

Every restore runs in a fresh container without leftover files or settings.

Easy to scale

Teams can increase the virtual machine size or run more machines during busy restore periods.

Cloud-ready setup

The workflow connects easily with Azure storage, automation tools, and monitoring services.

Real World Impact

Before using Docker and Azure, database restores were slow and difficult to manage. Engineers had to maintain multiple MySQL installations, and version differences often caused restore failures.

With Docker on Azure, teams can restore any MySQL version quickly without conflicts. The process becomes consistent, and engineers spend less time fixing issues.

[Need assistance with a different issue? Our team is available 24/7.]

Conclusion 

Managing restores across multiple MySQL versions becomes much simpler when Azure and Docker are used together. This setup creates isolated environments for each version, avoids conflicts, and allows engineers to complete restores in a more reliable way.