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
andphp_extensions.conf
to your new server prior to installation.You can preload the
options.conf
andphp_extensions.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 orphp
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 thens1
/ns2
lines and set themax_username
that may be longer on a source server. Other settings are more or less dynamic or server specific.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 partners 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.
Backup all the users using
Admin Tools
->Admin Backup/Transfer
:- Schedule
- Who - All users
- When - Now
- Where -
/home/admin/admin_backups/
- What - "All Data"
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
Use the same
Admin Tools
->Admin Backup/Transfer
to restore the accounts on the new server.Check for the status in
Messaging System
if all the accounts got restored successfullyDONE
B. (Average) Partial backups method with home sync
More steps, requires more knowledge, decreases the downtime as the home data gets transferred directly
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.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.
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.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.
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.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.
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.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!!!
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!
Rename the
mysql_new
directory tomysql
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.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 structureRun
da build roundcube
to recreate the grants for the roundcube database.DONE