Migrating accounts
How to transfer users between resellers
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:
- E-Mail arriving to box A, after the backup has been completed, but before box B is in used.
- Database entries updated on A after backup on A created.
- 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:
Make your** backup of fred on A**, and copy the gz backup to B normally (e.g., FTPS)
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.
We can now restore fred on box B normally via the Admin Backup/Transfer page, selecting the desired IP from box B.
Go back to the MSS page on B, and if A is listed, turn on the "Domain Check" again.
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.
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:
- 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.
**Transfer and restore **the User's tar.gz backup file normally.
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' 1.2.3.4:/home/username/domains/ /home/username/domains/
where 22 can be replaced with a different port number, and 1.2.3.4 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.