recovering from disaster....

I am needing to replace and existing older server.
old is ns10 new is ns11
I've setup ns11 as deb12 with --use-certbot
now I can migrate from old centos to new deb12.
but I want to retire the ns10.
on new server I can rename ns11 to ns10 and change the static internal ip. now all references to ns10 will come to new server.
renaming in hostname, and i ispconfig from ns11 to 10 of course.
is this sufficient? as the router routes external static to the internal ip (192.168.2.15 will turn into 192.168.2.20) is there anything else I need to do?
or will the new server now perform properly?

cdb.

 

ns10 is a primary dns server. it also has websites, emails, mongodb, various other things.
not a multiserver setup.

 

I believe I've found a bug in the migration process.
I ran it and we got to a point where it reported
[WARN] Source dir/file /var/www/clients/web8/web/nextcloud/ for web server does not exist. Skipping sync job.

This was correct, that folder I had deleted. but there was an entry under vhost for nextcloud.cdbsystems.com referring to this folder.

later when we got the line:
Replacing /var/www/clients/client0/web8/web/nextcloud by /var/www/clients/client0/web/web in /var/www/c....

but the migration task HUNG at this point. hours later we were still at 'Replacing' with no further action.

I control-c'd out and reran migration after deleting the vhost with the missing folder, but surely migration should not hang up??
anyway I'm doing the migration currently and we are well past this point!

 

agreed thats whats messing things up - but why would not the dry run detect things that will break the migration before starting doing it?
dryrun said all was good!
I've spent many hours so far attempting the migration, and 3 times now it has hung, always with 'Replace' command the last thing being issued. a reality check before beginning the migration might be of great benefit! what about that command is hanging anyway?

 

I've deleted the vhosts and trying again....
but some (hopefully useful) oberrvations? might be nice if migrate had a 'recover' to start where it left off? yo seem to be logging everything nicely. that way I dont have to go through the whole slog if I know nothing has changed!

 

now rsyncing mail maybe this time is the charm!
GREAT tool btw

 

alas it seems migtool locks all databases up and email was unreachable by roundcube. got up to 3527/4171 but I had to kill it to stop the screaming from customers
it was sitting at dumping database c0mazdaworld... may not be important anyway

any way to have it start at dumping databases? seems it got through all sync /var/lib/vmail tasks...

 

also whats left after dumping the databases? maybe I can move them over via usb.

 

well the migration has hung 3 times at the same mysqldump command on the same database... gotta be a problem with that database. I'll try to see if I can determine a problem, but it spent many hours stuck at the command- and at the same time roundcube (which depends on a db) always and instantly reported 'database connection error'. till I killed migration, then roundcube worked instantly.
can I move this database to the /root folder and hopefully migration will ignore it?

 

in phpmyadmin i'm unable to copy the database gives a 504 error even though max_execution_time set to -1 (infinity) and the max_memory set to 2048M. surely 2g is enough?
any other ideas?

 

Have you repaired the database as advised?

2gb is more than enough but infinity exec time? that is is a little bit crazy to me because its purpose is to fail at some prescribed time.