Migrating accounts

Server to server transfer of all accounts.

To transfer all of your accounts to a new server, you'll need to follow a few steps.

  1. First, DirectAdmin needs to be installed on the new server. For licenses with support, open a ticketopen in new window to request a free temporary migration license. For licenses out of support (e.g. legacy lifetime) please purchase a license at your own expense, and cancel it when the migration is finished. Proceed to Step 2. Once the migration is complete, request removal of the new license and then put the new server IP address into your original license, which can be done in your Client Account Areaopen in new window.

  2. For each IP that you are using on the old server, you'll need to add a new corresponding IP to the new server. Plan out which IPs will match up. Go to Admin Panel -> IP Manager on the new server, and add all of the IPs. You can change the IP assignment of the user when doing the transfer. For example, If they are currently on an owned IP address, it's quite easy to transfer everyone to a shared IP address, so if you don't have as many IPs, that's not a problem. Similarly, you can add users to owned IPs if they were shared on the old server.

  3. For each Admin/Reseller account on the old system, they will have to be created through DA the usual way on the new system (does not apply if you're using Admin Backup/Transfer). If the User backup files of the Reseller/Admin (their personal user files) were just restored, their account would be created as a user. This is why their account needs to be first created. Once each Reseller/Admin are created, go to Admin Panel -> IP Manager and assign each one whichever IPs they'll need to be using.

  4. On the old server, for each Admin/Reseller, log in as them, and go to their Reseller Panel -> Manage User Backups. Select all accounts, and make a local backup of those accounts. We recommend doing a local backup and then transferring the files over to the new server manually. You can try to use the FTP feature to upload to the same Admin Reseller on the new server, but you'll have to make sure the firewalls are set up correctly first (try it and make sure the files extract properly before doing all accounts). When uploading the backup files to the new server, place them in /home/reseller/user_backups, where reseller is the name of the admin/reseller who owns those accounts (including his own personal files). Make sure that the user_backups directory is owned by that Admin/Reseller and that the backup files in that directory are chmod to 755 (needs to be readable by the User that is being restored).

The newer alternative for the Reseller Level Backups is Admin Level -> Admin Backups/Transfers. It's essentially the same thing, except the file naming is slightly different and it can all be done from one screen (no extra logins required), and you can skip step 6 as Reseller Level settings are included in this system. Restore the Admins and Resellers first. (Admin Backups/Transfers also creates Resellers as Resellers, not users, so there is no need to create an empty template account first, since the restore does it all for you).

  1. On the new server, for each Admin/Reseller, login and go to Reseller Panel -> Manage User backups. For all accounts shown in the list, restore them. If you are assigning different users to different IP addresses, you'll have to do 1 restore per IP with which ever user(s) you are restoring. E.g., if 5 users are going to 1 shared IP, select those 5 users, select the shared IP and restore them. (Make sure you set that IP to be "shared" in the Reseller Panel -> IP Assignments first). If you are restoring 1 user to his own shared IP, he'll have to be restored by himself without any other users. Repeat the restore process for all users until complete. When restoring Admin/Reseller user accounts, the IP selection doesn't matter as their user account is already created.

  2. The restore process for Reseller Level settings will have to be copied manually. To copy the Reseller's packages over, copy the contents of /usr/local/directadmin/data/users/reseller/packages/* and /usr/local/directadmin/data/users/reseller/packages.list over to the new server with the same settings. The reseller will also have to set up any nameserver settings again (DNS info isn't restored), so make sure that the default nameservers are set in the Reseller Panel -> Nameservers before restoring the users.

How to transfer users between resellers

Related to the featureopen in new window

This feature is available in Admin Level -> Account Manager -> Move Users between Resellers. Or by appending /CMD_MOVE_USERS to the end of your URL. For example, https://yourdomain.com:2222/CMD_MOVE_USERS.

Here you can choose what users to move from one reseller to another.

Because this tool is an interface for the move_user_to_reseller.sh script you can also move users in your terminal. This can be done with the following command:

User to be moved:
Reseller that owns the user:
New reseller that will own the user:

The command to use in console is as follows:

/usr/local/directadmin/scripts/move_user_to_reseller.sh 'user' 'old reseller' 'new reseller'

How to avoid sync issues with the backup/restore process

We get this question a fair amount, where from the time you create a backup, transfer it, and restore the account onto a new server, then wait for DNS to propagate over, things like email or database updates could have already happened on the source box, which wouldn't show up on box B. Preventing all sync issues can be tricky to fully rule out.

Let's assume:

  • Box A is the source box, where the data is being backed up from.
  • Box B is the destination box, where data is to be restored to.

Main concerns:

  1. E-Mail arriving to box A, after the backup has been completed, but before box B is in used.
  2. Database entries updated on A after backup on A created.
  3. Users logging into box A and making various other changes.

When Transferring Users between servers, there are various tricks you can use to minimize these types of sync issues.

For all cases, lowering the DNS TTL value before the IP change is a good idea.

E-Mail arriving to A

This area is probably the simplest to address, as the SMTP system has its own built-in mechanisms to help us.

Assuming all accounts are going to be transferred from A to B, The simplest way to prevent any lost emails in the backup is to simply block port 25, so email cannot arrive to the box. Any one server trying to send to box A would have the emails temporarily rejected, but the sending server will try again later.

Other options, specifically for per-domain cases, would be to force Exim to return with a temporary error for this domain (not discussed here).

The 3rd option for email is to do the usual backup/restore from A to B, but at the last moment, perform an rsync, right before swapping the NS records.

Database Changes

This area is more difficult to keep synced. The simplest option is to do the usual User Backup/Restore normally, and at the last minute before swapping the NS records, issue a mysqldump/mysql transfer to the new box.

One trick, if the website or database is transferred first (either/or applies), you can change your database config setting to use the other server, so both boxes are temporarily using the same database. Note that MySQL calls outside of the same datacenter can be slow, so best to avoid this for too long. This method is handy, in case any clients are still pointed to the old DNS of A, even though you've got everything up and running on B. Swap the DB setting on A to point to the B DB server, in case any stragglers are still using A.

Beyond that, communication with the client about locking things like forums or other DB related areas is key to ensure nothing gets lost. Many major CMSs such as WordPress, for example, have a Maintenance Mode option that will prevent any updates to the database during maintenance such as transfers.

Other areas

Other concerns exist, but are typically less of an issue as long as you properly communicate with your clients. As long as they know not to create that new email account until tomorrow, for example, these things are typically not a major issue. You could go as far as suspending the current User on A while you do the backup to ensure the client does not change anything, just so long as you set up a 'down for maintenance' type page, instead of the standard suspended page (/home/admin/domains/suspended/index.html)

As mentioned above, ensure you do lower the TTL at least 4 hours before creating the backup, which will give you more options in case you need to flip/flop between IPs quickly.

Backup/Transferring Users between linked Multi-Server Setup boxes

The Admin Level ยป Admin Backup/Transfer tool can be used to move Users between 2 DA boxes.

However, if you have box A linked to box B with Zone Transfer and Domain Check, when you backup fred from A, and try and restore it on B, you'll likely get the "Domain Already Exists" error, since the zone is present on B.

A few extra steps are needed to make this work:

  1. Make your** backup of fred on A**, and copy the gz backup to B normally (e.g., FTPS)

  2. Before issuing the restore on B, we need to make a few changes in preparation:

    I. On box B, temporarily go to Admin Level -> Multi-Server Setup (MSS for short) If you have a two-way link (A-to-B and B-to-A), such that A is listed on that page, disable the "Domain Check" option. Leave the "Zone Transfer" enabled so that A gets the new B zone upon restore. You'll need to turn this back on after the restore is done.

    II. Since the fred.com zone is already on B, we need to tell DA not to use the named.conf as the domain index for restores. Instead, we'll tell it to use the /etc/virtual/domainowners. This is done via Admin Level -> Admin Backup/Transfer -> Backup/Restore Settings and check the option and save:

On restore, check for domain conflict in domainowners, rather than the named.conf, or remote named.conf files.
  1. We can now restore fred on box B normally via the Admin Backup/Transfer page, selecting the desired IP from box B.

  2. Go back to the MSS page on B, and if A is listed, turn on the "Domain Check" again.

  3. At this point, the fred.com domain** should resolve to B**, but via ns1 on A, and via ns2 on B (if you've set it up that way), as the restored fred.com zone on B should have been synced over to A.

  4. Deleting fred from A: When you have decided everything is working well and want to delete fred from box A, you must ensure you check the "Leave DNS" option when deleting the account. Go to Admin Level -> Show All Users, select the checkbox for User fred, and before clicking "Delete", ensure the "Leave DNS" is checked. (On the Evolution skin, there is a pop-up/confirmation page, where this checkbox lives).

Assuming all went well, both A and B should have the new fred.com zone containing the IPs from box B, and the account should exist only on box B.

Pulling data from a remote directory with rsync

Say you've got a User with massive amounts of data in /home/username/domains/.

The easier way to transfer the data is to:

  1. Create the backup file without the Domains Directory, over Admin Level -> Admin Backup/Transfer -> Create Backup.

In the "What" section, de-select the "Domains Directory" option and create the backup.

This will create a tar.gz backup file, without /home/username/domains, allowing the tar.gz to be much smaller.

  1. **Transfer and restore **the User's tar.gz backup file normally.

  2. Since we've skipped the domains directory, we must transfer that data manually. Rsync is the best tool to do this.

  • Login to the new box (B), where the data is being transferred to.

  • In ssh, as root (or the User you're transferring, if you want, but they need SSH access), type:

rsync -ave 'ssh -p 22' /home/username/domains/

where 22 can be replaced with a different port number, and is replaced with the IP of the old server (A). Watch the data fly by, as it's being pulled from the other server to this one.

For increased security, you could enable SSH on the old server (A) for the User being transferred, and change "ssh -p 22" to be "ssh -l username -p 22". This will ensure that only user-level access is used when reading files from A. You'd need to know the password of that User.

Last Updated: