HOWTO: Swift & painless server migration using Admin backup/restore

[Jackiegoal]

Sorry. Maybe I should start a thread "Swift & painless server migration using Admin backup/restore for the advanced admin."

Maybe it's the language thing, but I really don't mean your input isn't appreciated in any way. I was just trying to explain why I used these steps and not yours in the HOWTO. Your remarks in this topic are greatly appreciated and very useful for many people on these forums. I hope we're clear on that.

 

[jjma]

Now, we'll start by backing up all accounts on the old server. I don't know how your server is setup, but I always advise not to transfer the admin account along with the other accounts. If you're experienced with DA, you'll know not to use the admin account too much and use a reseller account for all the rest, but if you didn't, well, you'll have to backup the admin account as well.

Can you explain this in a bit more detail.

I started my directadmin experience by creating an admin user and since then have created users via the admin user (there are no resellers) thinking this was the correct procedure?

Jon

 

[floyd]

If you're experienced with DA, you'll know not to use the admin account too much

I would like to know the logic behind that too since I have been using DirectAdmin for 4 years with over 70 servers.

 

[nobaloney]

At least reason come to mind:

The admin account restore changes your main server admin password.

There are probably lots of other subtle things copied over as well which you not want copied over.

Jeff

 

[floyd]

I have done it many many times and never had a problem except the admin password like you said and I just reset that from the command line. But after all we are talking about entire server migration not combining one or more servers into one. Moving all the users from an old server to a new clean server. The new clean server should not have anything under the admin account anyway at that point.

 

[Jackiegoal]

Can you explain this in a bit more detail.

I started my directadmin experience by creating an admin user and since then have created users via the admin user (there are no resellers) thinking this was the correct procedure?

Jon

Well, in fact, it's basic sysadmin knowledge: always limit your permissions to what you explicitly need. This means that you do your server administration using an admin account and your user administration using a (seperate) reseller account. This has many advantages including, for example, limiting employees in what they can and cannot do, but also limiting possibilities to "screw up" on admin level. I agree that DA doesn't have a very extended permission system and you might want to consider, for example, setting up certain external "control panels" using DirectAdmin's API, but if you don't, this is actually the way to go IMHO.

Besides that, as Jeff wisely remarks, backing up and restoring the "normal" admin account has some disadvantages. The advantage with not using the admin account for anything but server administration is that it is not needed to backup and restore your admin account, it's good as empty. When setting up the new server, you rarely need to setup anything in the admin account after DA's installed.

In fact, if you really follow the instructions of this HOWTO, you might even get locked out of your server. ELS disables direct SSH root login and you will not be able to login using the admin account after restoring it. I'm sure there's a workaround for that (using a user account that has SSH access and SU for example), but I'd consider not to risk anything at all.

 

[Jackiegoal]

I have done it many many times and never had a problem except the admin password like you said and I just reset that from the command line. But after all we are talking about entire server migration not combining one or more servers into one. Moving all the users from an old server to a new clean server. The new clean server should not have anything under the admin account anyway at that point.

That is true. If, for any reason, you have decided to use the admin account as your reseller and maybe even your company's website account, you will want to backup the admin and you will probably not face any complications besides the password issue. I included that possibility in the HOWTO.

 

[floyd]

Well, in fact, it's basic sysadmin knowledge: always limit your permissions to what you explicitly need.

That is a broad general comment. That is very true in probably most cases for most people. But not for me.

backing up and restoring the "normal" admin account has some disadvantages.

So don't back and restore the admin user. That has nothing to do with the users that were created under admin. They can be backed up and restored individually.

 

[jca]

I must say that this guide really helped me migrating servers, the suspend idea was great, as when I suspended I changed the DNS and when the user was restored on the new server almost everything was working. Thanks for the ideas.

I might add I would love to see how to make the iptables thing work as to avoid the dns cache and send them to the new server right away.

 

[jjma]

Well, in fact, it's basic sysadmin knowledge: always limit your permissions to what you explicitly need.

In this case this is what I needed i.e restore the previous admin user.

In fact, if you really follow the instructions of this HOWTO, you might even get locked out of your server. ELS disables direct SSH root login and you will not be able to login using the admin account after restoring it. I'm sure there's a workaround for that (using a user account that has SSH access and SU for example), but I'd consider not to risk anything at all.

Which is why I use the ELS script to install some but not all of it's parts as I prefer to maintain the security of the server myself.

Jon

 

[jca]

Personally I don't like allowing admin account ssh login. As if anybody who "scans" my servers will find out I run directadmin, so trying to brute-force using the admin username will bring them nowhere. I always setup a personal non-directadmin account on the server to enter by ssh, and disable root & admin ssh login.

 

[Internet54]

I usually get the server setup.
Do a admin backup.
Import that backup.
FWD the IP's to the new server.
RSYNC the home directory and mysql data.
Change the nameservers to the new IP's.

Forwarding the IP's works wonders and keeps the sites a float until the complete move is done.

 

[floyd]

I usually get the server setup.
RSYNC the home directory and mysql data.

On a busy server that is dangerous as mysql data could change on the new server before you start the rsync.

The safest way is to suspend the user and then do the backup. That way nothing changes during the transfer.

Your way is great for maximum uptime but not for data integrity. How you do it depends on what you value the most.