aaPanel/BaoTa Backup and Migration: Move Websites and Databases to a New Server

Whether for everyday protection or for upgrading to a larger IMIDC server, aaPanel/BaoTa backup and website migration is a task every site owner faces. This guide applies to aaPanel / BaoTa Linux panel on Debian/Ubuntu and CentOS/Rocky/AlmaLinux. It covers scheduled panel backups, backups to remote storage, the general workflow of the one-click migration plugin and the most reliable manual method — tar for files plus mysqldump for databases — followed by a DNS switch checklist for a migration without data loss.

Step 1: Schedule Website and Database Backups in aaPanel/BaoTa

Open Cron in the panel sidebar and create tasks of type "Backup Site" and "Backup Database". Select all or specific sites, run them daily at night and keep a sensible number of copies (for example 7) based on disk size. Backups are stored in /www/backup by default; check them with:

ls /www/backup/site /www/backup/database
du -sh /www/backup/*
df -h /www

Step 2: Send aaPanel Backups to Remote Storage

In the panel App Store, search for and install a storage plugin (FTP, S3-compatible object storage and similar), enter its access details, then edit your Cron backup tasks and choose that storage as the backup destination. Another IMIDC server can also serve as an FTP or rsync target for off-site disaster recovery.

Step 3: Use the One-Click Migration Plugin (Whole-Server Moves)

The panel vendor offers a one-click migration plugin. The general workflow: install the same panel on the new server, enable its API interface in panel settings and whitelist the old server's IP; on the old server install the migration plugin, enter the new panel's address and API key, select the sites, databases and FTP accounts to move and wait for the transfer. Plugin names and screens change between versions, so follow what your panel shows. Keep PHP and MySQL versions the same on both servers.

Step 4: Manual Migration — tar the Website and mysqldump the Database

When the plugin fails or you only move a few sites, the manual method gives you full control. Run the following on the old server (replace example.com and example_db with your site directory and database). --single-transaction produces a consistent InnoDB dump without locking tables.

# On the OLD server
mkdir -p /root/migrate && cd /root/migrate
tar -czf example.com.tar.gz -C /www/wwwroot example.com

# Export the database (consistent dump for InnoDB, keeps utf8mb4)
mysqldump -uroot -p --single-transaction --routines --triggers \
  --default-character-set=utf8mb4 example_db | gzip > example_db.sql.gz

# Copy the Nginx vhost and rewrite rules for reference
cp /www/server/panel/vhost/nginx/example.com.conf /root/migrate/
cp /www/server/panel/vhost/rewrite/example.com.conf /root/migrate/rewrite-example.com.conf 2>/dev/null
ls -lh /root/migrate

Then push the files to the new server with rsync, which resumes interrupted transfers and handles large files better than scp:

# Debian / Ubuntu
apt install -y rsync
# CentOS / Rocky / AlmaLinux
yum install -y rsync

# Push the files to the NEW IMIDC server
rsync -avP -e "ssh -p 22" /root/migrate/ root@NEW_SERVER_IP:/root/migrate/

Step 5: Restore the Website and Database on the New Server

In the new panel, first add the site with the same domain, create the database and user with the same name (note the password) and install the same PHP extensions. Then extract the files, fix ownership and import the database. If the database password changed, update the site configuration (for example wp-config.php in WordPress). Reconfigure rewrite rules and SSL in the site settings; our "BaoTa website and SSL" guide explains how.

# On the NEW server, after creating the site and the empty database in the panel
cd /root/migrate
tar -xzf example.com.tar.gz -C /www/wwwroot/
chown -R www:www /www/wwwroot/example.com

gunzip < example_db.sql.gz | mysql -uexample_db -p example_db

Step 6: Test the New Server with Your Local hosts File

Before changing DNS, point the domain to the new IP in your own computer's hosts file and test the home page, admin login, uploads and payments. Remove the line when you are done.

# Windows: C:\Windows\System32\drivers\etc\hosts
# macOS / Linux: /etc/hosts
NEW_SERVER_IP  example.com  www.example.com

Step 7: DNS Switch Checklist

• 24-48 hours ahead, lower the TTL of the A record to about 300 seconds;
• pick a low-traffic window and enable maintenance mode or pause admin writes;
• dump and import the database once more and run an incremental rsync of uploads (commands below);
• update the A record to the new IP and issue or deploy SSL on the new server;
• watch the old server's access log until traffic stops, and keep the old server for several days before cancelling it.

# Final sync of uploads changed since the first copy (run on the OLD server)
rsync -avP /www/wwwroot/example.com/ root@NEW_SERVER_IP:/www/wwwroot/example.com/

# Verify DNS after switching
dig +short example.com A
nslookup example.com 8.8.8.8

FAQ

After migration the site shows the panel default page or 404.

DNS may not have propagated yet, the site may be missing a domain alias (with and without www), or the document root differs from the old server. Check the domain list and root directory in the site settings.

Import fails with a charset or "Unknown collation" error.

The new MySQL is usually older and lacks collations such as utf8mb4_0900_ai_ci. Install the same or newer MySQL version, or replace the collation in the dump with a compatible one.

The backup is huge and transfers slowly.

Do a first full rsync while the site is still live, then only an incremental sync during cutover. Downtime drops to a few minutes.

Still stuck after following these steps? Open a support ticket and the IMIDC 24/7 technical team will help. Please include the server IP, OS version, the commands you ran and a screenshot of the error so we can pinpoint the issue faster.