Directadmin Docs

Full Directadmin migration

1. Server preparation

DirectAdmin needs to be installed on the new server.

Open a ticket to request a free temporary license for migration. Use this key to install DirectAdmin on the new server. Once migration is complete, apply your original license key to the new server.

Legacy Licenses: No temporary license is possible, as legacy keys can no longer be deployed. Another legacy license must be used for migration. Deploying a new key for migration will fail because the new installation will reject downgrade to a legacy product.

Methods for the installation

  • A. (Easy) Use default installation

    The whole install is one command which installs all the currently recommended php versions and software. This is usually recommended for most of the users if no custom versions or software is required.

  • B. (Average) Preload some important variables prior to install

    #example:
export DA_EMAIL=email@example.com
export DA_NS1=ns1.example.com
export DA_NS2=ns2.example.com
export php1_release=8.0
./setup.sh LICENSE_KEY

  • C. (Advanced) Preload options.conf to your new server prior to installation.

    You can preload the options.conf. Additionalyl you can sync the whole /usr/local/directadmin/custombuild/custom/ directory to the new server prior to starting the ./setup.sh LICENSE_KEY (useful when you want to create destination server with the same settings as your source server).

    Note: please check beforehand if the current version of directadmin supports the same versions as your source server. Because if you'll have a mysql/mariadb version or php version too old in there - the installation will not complete due to invalid setting. You can restart the ./setup.sh once you fix the issue.

2. Things to consider before the migration

  • DNS - the most important part before planning a migration is DNS. Who controls the DNS zones for the domains that you're going to transfer?

    • Check if all domains on your server are controlled by your DNS servers. If not - users will have to change DNS records to point to new server manually themselves.
    • Lower the TTL before the migration.
    • Registrar changes may take unexpectedly longer (even 24h and more). If you need to change glue records or DNS servers for your migrated domains after migration - we recommend updating the DNS zones to point to the new location in both - the source AND the destination server, as the behavior of DNS records themselves is more predictive than API calls between the registrars and whatnot. This will make the registrar changes to be transparent to your users.

  • /usr/local/directadmin/conf/directadmin.conf is usually safe to leave the default version with new defaults. You may just want to modify afterwards the ns1/ns2 lines and set the max_username that may be longer on a source server. Other settings are more or less dynamic or server specific. But if you have your own settings/modifications in "directadmin.conf" file, you can copy it too.

  • Do not forget to re-save the backup tasks.

  • Check for YOUR custom templates: /usr/local/directadmin/data/templates/custom and scripts /usr/local/directadmin/scripts/custom. Do not blindly copy those, as many stuff may be simply part of the plugins used on source server.

  • Do not forget to reconfigure the multiserver if you used it.

  • do not forget to check your php.ini settings for your all php versions if you had any.

3. Transfer methods

Here are 3 methods for a FULL directadmin to directadmin server migration. While the 1st Full backup method has the most downtime - it's the easiest to accomplish. The more advanced technique the more downtime it may save, however, making a mistake may have bigger consequences.

The advanced techniques could be pushed even further by executing a "2 stage" migration, by doing one migration in advance, and then repeating the same steps at the final migration date to save time as the 'rsync' for a /home directory that already contains data will be much much faster.

If you have trouble migrating the server, you could potentially contact our consulting system administration partnersopen in new window that could do the migration for you.

A. (Easy) Full backups method

Less steps, easier for new users, but bigger downtime. Recommended for new users.

  1. Backup all the users using Admin Tools -> Admin Backup/Transfer:

    • Schedule
    • Who - All users
    • When - Now
    • Where - /home/admin/admin_backups/
    • What - "All Data"

  2. Copy the /home/admin/admin_backups/ to your destination server /home/admin/admin_backups/

    #example with rsync
rsync -av /home/admin/admin_backups/ root@dest_server_ip:/home/admin/admin_backups/ --delete

  3. Use the same Admin Tools -> Admin Backup/Transfer to restore the accounts on the new server.

  4. Check for the status in Messaging System if all the accounts got restored successfully

  5. DONE

B. (Average) Partial backups method with home sync

More steps, requires more knowledge, decreases the downtime as the home data gets transferred directly

  1. Follow the 1, 2 and 3 steps as in A. Full backups method, but with one exception when creating the user backups:

    What tab - Press on "All" but un-select "Domains Directory" & "E-mail Data".

    This will create a backup with all the user related settings and database, but without data in user home directory.

  2. Double-check in the messaging system that all the users were restored and retry/fix the ones that failed.

    Note: It's important to verify existance of all the users before syncing the /home as non-restored users will have numeric UID, which will prevent you from succesfully restoring users via GUI afterwards.

  3. Rsync the whole /home from source to destination server:

    rsync -av --progress --delete /home/ root@dest_server_ip:/home/

    Note: this is destructive action and will delete everything that exists in destination server /home/ directory.

  4. DONE

C. (Advanced) Partial backups with home and mysql sync

This is an advanced technique that requires to check the compatibility between the database versions, control the precesses, and change appropriate configuration files.

IMPORTANT: If any of the steps here raises questions - use the simpler method. You may loose the data if executed incorrectly.

  1. Follow the 1, 2 and 3 steps as in A. Full backups method, but with one exception when creating the user backups:

    What tab - Press on "All" but un-select "Domains Directory" & "E-mail Data" & "Database Settings" & "Database Data".

    This will create a backup with all the user related settings and database, but without data in user home directory and database related info/data.

  2. Double-check in the messaging system that all the users were restored and retry/fix the ones that failed.

    Note: It's important to verify existance of all the users before syncing the /home as non-restored users will have numeric UID, which will prevent you from succesfully restoring users via GUI afterwards.

  3. Rsync the whole /home from source to destination server:

    rsync -av --progress --delete /home/ root@dest_server_ip:/home/

    Note: this is destructive action and will delete everything that exists in destination server /home/ directory.

  4. Stop mysql/mariadb on both servers and make sure that they are stopped during the whole syncing process! (either stop via GUI, or disable it in /usr/local/directadmin/data/admin/services.status)

    #example on SOURCE and DESTINATION
sed -i -e 's/mysqld=ON/mysqld=OFF/g' /usr/local/directadmin/data/admin/services.status
systemctl stop mysqld
# MUST BE OFF ON BOTH SERVERS DURING THE SYNC!!!

  5. Rsync mysql to the new server:

    #example on SOURCE
rsync -av --delete --progress /var/lib/mysql/ root@dest_server_ip:/var/lib/mysql_new/

    Re-execute the same rsync command again to "verify" that nothing has changed on the source server in that mysql dir. If it did - likely mysql was NOT down during the sync!

  6. Rename the mysql_new directory to mysql

  7. Copy /usr/local/directadmin/conf/my.cnf and /usr/local/directadmin/conf/mysql.conf files from the source server for DA to know the access details to DB.

  8. Start mariadb and verify the health of the data. Run mysql_upgrade in case the destination server has a newer supported version of database to upgrade the structure

  9. Run da build roundcube to recreate the grants for the roundcube database.

  10. DONE

Last Updated: