recovering from disaster....

i'm working on repairing some of the listed errors in the mariadb log, but when I go to the table it says has invalid info - it says 'in use'.
also in the log i'm seeing lines like:
2025-10-20 9:23:19 341856 [Warning] Aborted connection 341856 to db: 'dbispconfig' user: 'ispconfig' host: 'localhost' (Got an error writing communication packets)
ouch? whats going on??

 

2 of the tables that mariadb.log reports errors in phpmyadmin has both of them (but no other table) marked as 'in use'.
how do I repair it in this case?

 

yes it fails:
c0theeldestgeekx.wp_jet_reviews repair Error Incorrect information in file: './c0theeldestgeekx...
c0theeldestgeekx.wp_jet_reviews repair error Corrupt
c0theeldestgeekx.wp_jet_review_comments repair Error Incorrect information in file: './c0theeldestgeekx...
c0theeldestgeekx.wp_jet_review_comments repair error Corrupt

but with the one database (mentioned before) excluded, migration completes - with only the c0theeldestgeekx database reporting:
mysqldump: Got error: 1033: "Incorrect information in file: './c0theeldestgeekx/wp_jet_review_comments.frm'" when using LOCK TABLES [4163/4163]
=============
Migration tool run completed.

so... now if I try to fix or delete the base and do a ./migrate --syncjobs we will be good? hopefully
(or is it sync-jobs?)

 

one more thing I noticed. you aware the auto-installer for debian does NOT create the
/var/log/mysql
directory with ownership mysql:mysql and 2750 permissions, so that mariadb cannot write a logfile till this is done?

 

another migration related question - if I implement the ssh-authenticator 2fa on the target server, migration cant handle that I assume? have to disable it at least temporarily? or is there a way to satisfy it?

 

ok one more issue. multifaceted!
the datarecovery lab has recovered my 60tb raid 6 array and i'm getting back a 12tb single drive with what looks like the correct directories for debian 12.
so I see the /var/www /var/vmail/ /var/lib (including mysql).
now I can attach this drive as an external drive.
what procedure do I use to 'restore' the emails databases etc?
the users have /var/vmail now. can i merge the /var/vmail/usernanme folder off the recovered drive into the folder on this server? and rebuild the index? or no need. any rammifications?
to bring up a website (that was on the new server but not the old one).
can I create a blaink website, then copy over the /var/www/domain/web folder, and copy the corresponding database from /var/lib/mysql on the external drive to /var/lib/mysql on my working server?
or do I need to create the website & database in ispconfig, and then copy the /var/www from the external, and copy the database with cp from the external drive ontop of its /var/lib/mysql name?
what will I run into? I assume I need to fix permissions as it will all be root:root.
what a disaster
oh - old server is running centos8 dead server was debian12.
or - alternate idea - can I put the 12tb drive into a server and boot from it? any risks? the data wants to end up on another raid array, but can I build up a raid array on another server, install deb12, and then masscopy from the external 12tb drive? which folders and what do I need to be aware of>

what a nightmare. but $8k recovery was actually pretty dam reasonable. they are saving my life.
Help me till!

 

thats a good idea. I will ask him!

 

something I just noticed. from migration from centos to deb12, mailman is NOT supported. it gives a couple of errors regarding that.
but on the target server, mail does NOT work. and errors say no /etc/mailman/alias file (or something very close).
why would the mail system on the target system need it?
emails sent out get stuck in the queue and mailq says:
8E504FE08B3 3778 Tue Oct 28 12:35:16 MAILER-DAEMON
(alias database unavailable)
and when I run newalias I get:
root@ns11:/etc# newaliases
postalias: fatal: open /var/lib/mailman/data/aliases: No such file or directory

those are infact symlinked to /etc/mailman folder that does NOT exist!
thoughts?

 

I think because old system have it, so it was copied, but you could try to remove it from alias and see how it goes. Just refer to the latest manual install there is if you are unsure on how and where to remove it. It should be easy.

 

Till looks like I need to delete all reference to mailman before doing the migration
But shouldn't migration script fix target that does NOT support mailman?
How to delete it from source server?

 

If you have done the migration, I think it is easier if you just clean up the new system from its related configs, as the new system, normally setup using ISPConfig auto installer doesn't install mailman.

About migration tool, as a disclaimer I have never used it before so I would not know, but I migrated some manually and update some from with mailman to no mailman, so I could say it is easy.

For mailman removal, try: https://www.howtoforge.com/update-t...rom-debian-10-to-debian-11/#-clean-up-mailman

Also, may be the best if you could check the migration tool help function, if there exists any for mailman exclusion, or just wait for @till to explain and help.

 

till, I used ONLY the migration tool. not ISPCopy. and I've reported the errors I was running into.
I copied over NO folders, and I installed deb12 with the automated installer only! on a blank system.


there are CLEARLY mailman references on the deb12 system. for example in /etc/postfix a grep of the files produces:

main.cf~:transport_maps = hash:/var/lib/mailman/data/transport-mailman, proxy:mysql:/etc/postfix/mysql-virtual_transports.cf
main.cf~3:alias_maps = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases
main.cf~3:alias_database = hash:/etc/aliases, hash:/var/lib/mailman/data/aliases
main.cf~3:virtual_alias_maps = hash:/var/lib/mailman/data/virtual-mailman, proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf, proxy:mysql:/etc/postfix/mysql-virtual_alias_maps.cf, proxy:mysql:/etc/postfix/mysql-virtual_email2email.cf

I did NOT copy /etc/postfix from the old server I've used no tool but the migration (which had to be used several times as I've reported) - so inquiring minds want to know how did these get here?

 

in case you ask, I did NOT install mailman3 on the new server:
root@ns11:/etc/postfix# apt list | grep mailman

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

mailman3-doc/oldstable 3.3.8-2~deb12u2 all
mailman3-full/oldstable 3.3.8-2~deb12u2 all
mailman3-web/oldstable 0+20200530-2.1 all
mailman3/oldstable 3.3.8-2~deb12u2 all
python3-django-mailman3/oldstable 1.3.9-1 all
python3-mailman-hyperkitty/oldstable 1.2.1-1 all
python3-mailmanclient/oldstable 3.3.5-1 all
root@ns11:/etc/postfix# apt list mailman3
Listing... Done
mailman3/oldstable 3.3.8-2~deb12u2 all
root@ns11:/etc/postfix# apt list --installed | grep mailman

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

root@ns11:/etc/postfix# apt list --installed | grep mailman3

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

root@ns11:/etc/postfix#


mailman3 is available but was never installed!

 

im going to build up another server with deb12, and do the migration to that server - see how it works!
given that mailman gives ERROR during the migration I assume its moving NOTHING over, right?