Postfix issues after backup/restore to a new VPS

SYSTEM INFORMATION
OS type and version Debian12
Webmin version 2.303
Virtualmin version 7.30.8
Webserver version LAMP
Related packages SUGGESTED

I have been battling this for over a day now and running out of ideas:
I did backup all domains on my original VPS running Ubuntu20.04, created a new KVM based VPS with Debian12, installed the latest Virtualmin set the hostname etc to a subdomain of one of my domain names and started restoring the backups.
After changing the DNS records I could verify the websites are all fine, but the mail subsystems are annoyingly not cooperating. I did run a few hours of Gemini sessions which ended in purging and reinstalling postfix, then we figured that postgrey was on a wrong port etc.
Would anyone have a clue, why this would be happening? Or more importantly what to do to fix all this?

I am currently thinking of spinning up yet another VPS this time installing Ubuntu 20.04 and restoring the backups onto that. If that would run, then I would sync emails from the non-functioning VPS to this one and start from scratch again?

At this point I am interested in any advise. I realize the information given is not very specific, so please ask.
Cheers
Stefan

Very good.

Very good again. This subdomain is unused, right? This subdomain that you are using as hostname of the new server is not doing double duty as the domain name of one of your virtual servers under Virtualmin, right?

Your statement is vague. Is incoming mail from a remote system bouncing? Why? DNS propagation? Is incoming mail from a local system bouncing? Is incoming mail from another virtual server bouncing? Is outgoing mail being delivered? Delivered and flagged as spam. Why exactly do you mean by ā€˜not cooperating’?

That’s not a good idea…

That’s a bad idea.

I stop here. You need to install Virtualmin on a server with a freshly installed OS and restore from backups again.

Yeah I figured, that Gemini was leading me into all sorts of directions. I am ok with starting again - though my clients will not like the delay …
Naming convention: OLDVPS the original, VPS1 = the currently malfunctioning VPS, NEWVPS the one I need to setup to start again

Would you start with any OS (like I did with Debian12) or would you start again with the old Ubuntu20.04 from the original OLDVPS?
Obviously I now have the extra issue, that I can use the backups from OLDVPS, but then I need to sync all the email accounts which had been arriving on VPS1.
But like you pointed out my first priority is to get a working system.

Would you use backups from the misconfigured VPS and restore these on a brand new installed VPS, or use the backups from the original machine (and then do imapsync to migrate the mails from the misconfigured VPS to the brand new)?
I guess when taking backups from the misconfigured VPS I should NOT restore the virtualmin settings, but use the settings from the original VPS?

You haven’t explained what issues you are experiencing. After restoring the domain, what problems are you seeing? Are you unable to send, receive email? Are you seeing an error message? Please describe what caused you to go looking for a solution and what solution you are actually looking for when searching Gemini.

@tpnsolutions
Yes you are right,so lets start with that:
After installing Debian12 and Virtualmin, I transferred all backups from the original VPS (Ubuntu20.04) over and restored then. The new VPS has a different hostname of course.
Initially I forgot to set the PTR so the reputation went down, but the system did receive emails and I could see them in Thunderbird (IMAP).
Then I noticed that I could not send emails. I am investigating why postfix is not starting. This is what I see currently:

systemctl status postfix.service
Ɨ postfix.service - Postfix Mail Transport Agent
Loaded: loaded (/lib/systemd/system/postfix.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Sun 2025-06-01 09:31:03 NZST; 38s ago
Duration: 10min 54.175s
Docs: man:postfix(1)
Process: 1255991 ExecStart=/usr/sbin/postfix start (code=exited, status=1/FAILURE)
Main PID: 1255991 (code=exited, status=1/FAILURE)
CPU: 22ms

Jun 01 09:31:02 vps.domainname.nz systemd[1]: Starting postfix.service - Postfix Mail Transport Agent…
Jun 01 09:31:02 vps.domainname.nz postfix/postfix-script[1255999]: fatal: the Postfix mail system is already running
Jun 01 09:31:03 vps.domainname.nz systemd[1]: postfix.service: Main process exited, code=exited, status=1/FAILURE
Jun 01 09:31:03 vps.domainname.nz systemd[1]: postfix.service: Failed with result ā€˜exit-code’.
Jun 01 09:31:03 vps.domainname.nz systemd[1]: Failed to start postfix.service - Postfix Mail Transport Agent.

journalctl -xeu postfix.service
Does not reveal anything

ps fax shows:
1255988 ? Ss 0:00 /usr/lib/postfix/sbin/master -w
1255989 ? S 0:00 _ pickup -l -t unix -u -c
1255990 ? S 0:00 _ qmgr -l -t unix -u
1255992 ? S 0:00 _ cleanup -z -t unix -u -c
1255993 ? S 0:00 _ trivial-rewrite -n rewrite -t unix -u -c
1256011 ? S 0:00 _ tlsmgr -l -t unix -u -c
1256016 ? S 0:00 _ smtpd -n smtp -t inet -u -c -o stress= -s 2 -o smtpd_sasl_auth_enable=yes -o smtpd_tls_security_level=may
1256017 ? S 0:00 _ anvil -l -t unix -u -c
1258775 ? S 0:00 _ local -t unix

I have now done a visual comparison between the original VPS and the new by going through all Postfix config screens in Webmin, but there were only minor differences. I did then do a restart, which again resulted in the error above.
I’m out of ideas.

Before restoring test everything is working first. Then maybe just restore one domain.
I presume you are using Virtualmin backup and restore.
I’ve done many times without issues.

I’ve done this before - a few years back though. This time I tried to go from Ubuntu20.04 to Debian12 in one go - too much in one? The website/database stuff worked - no problems. It is the mail side of the server that is giving me the headache.
Should I start all over again with a fresh install as painful as it is?

I always do a test run.
How are you doing the restore, you said something about sync, I’ve never used a sync program just virtualmins restore, its very quick normally.

bad choice of words maybe: I do use the backup/restore of virtualmin to move a virtual server from one VPS to another. The ā€˜sync’ is after everything is done and only included emails, because the changeover takes some time, during which emails might still be delivered to the original VPS. imapsync takes care of moving those over.

My basic question remains: Do I try to fix the mailing issue (might need someone helping for this) or do I start all over again? What would be the feeling?

Never had that issue, that why maybe just do one domain at a time and see if the error still happen. It maybe a configuration in one of the domains, like a bad certificate location for one domains.

Right - I think I need to start again. Would your recommendation be to use backups from the original VPS or the current VPS (that has the mail issues).
My gut feeling is that the underlying issue is not the individual domains but the postfix setup somehow had a glitch and then must have gotten worse with my attempts to fix it…

Original, you don’t want to restore issues. You vps should have snapshots, do one before the restore and then its quicker to try new things in the restore option. One option is not to restore mail server settings. Like that.
Sounds like you having fun NOT.

Definitely NOT fun - this is a live system with customers …
I am switching to full KVM VPS here in NZ for speed, so no snapshots. But I will simply spin up number three so I have the original and not loose anything from the currently running (misbehaving) system.
So if I read you right, you recommend to backup the domains from the malfunctioning VPS and restore them on the brand new one but unticking the Mail server settings? And the set them up manually in Virtualmin?

@pws,

Sorry I haven’t been active in the conversation, and kudos to @calport and @stefan1959 for stepping up and trying to offer some assistance.

I sent you a PM inviting you to a private conversation over WA, drop me a line if you’ve got a few minutes to spare, I’m confident I can help you get things sorted out or at least give you insights into what’s causing problems.

I’ll be available for a few more hours if you’re interested, but either way drop me a line on WA.

Oh gods. That’s not good. You really have to be so careful when letting AI tell you to do stuff. It sounds so confident, and it seems like it knows things, but it really doesn’t. It gets lucky sometimes, but the longer you use it, especially in a situation where you don’t actually know what’s wrong, the more likely you are to make things much, much, worse.

I’d really like if we could go back in time before the AI wrecked things. Whatever problems there were could have probably been fixed pretty easily.

I’ll mention that when restoring backups to different operating systems, you should expect problems. Usually minor. We try to accommodate the differences between systems, but config files and conventions are different in minor ways and can have surprising results, even between similar systems like Ubuntu and Debian. The safest bet is to stick with the same OS unless and until you have time to do some testing before flipping the switch on the domains and mail.

@Joe @calport @stefan1959,

I spent a few hours working with @pws over a screen sharing session and there was something a muck with Postfix. Either it didn’t complete a post-install correctly, got muddied while he was trying to resolve the issue initially, or something else all together.

After going through a series of patch this, patch that, as there was some oddities I was discovering, I decided to have him spin up a new VPS and conducted my typical refined install based on his needs.

I tested that email was working with a fresh domain, that we provisioned for this purpose, and addressed a few weird things that seem to have been setup by the distro but were easy enough to overcome.

I’ve provided some detailed ideas on how he should proceed with a ā€œrestoreā€, leaning towards a more manual restoration, but one which if executed correctly could reduce the time and streamline things for the most part. Another idea was to try importing a single domain, and/or a minimal set of features from the backup, test, verify, and continue if it worked as intended.

I’ve advised @pws to reach out and let me know how things are progressing, and request any further consultation should things not go quite as planned.

Much of the time spent chatting with @pws was about ideas to improve his use of Virtualmin, a bit of life, and business as a whole. He’s a great guy, and I look forward to guiding him in the future has he continues on his endeavors.

@pws thanks for the opportunity to help you work through this matter!

2 Likes

Like @tpnsolutions pointed out this was a really mucked up postfix. I agree with @Joe that AI is not always the best … lesson learned.
The new VPS is now starting to take shape, but after the initial backup/restore approach I will take the slightly longer more manual approach Peter suggested:

  1. create the server on the new VPS with the features needed 2) create the users 3) transfer website files and database over 4) test the new domain and when things look ok adjust the DNS records. 5) lastly I will use imapsync to transfer the emails for the users from the old to the new machine.
    Not a point and click, but still very manageable and in a controlled fashion.
    First I’ll setup a detailed plan for all jobs for all domains and then with a fresh mind start the actual ā€˜transfer’ tomorrow…
    It’ been a loooong 48 hours trying to get this to work, but @tpnsolutions Peter was great to work with (more he with me observing) and I can not praise him enough for taking on this project and ā€˜setting me straight’. Great chap!
    I will update this post once I am making progress. Upwards and onward!

I don’t think that’s necessary (doing everything manually).

I’m sure whatever problem occurred with restoring backups was something simple and easy to fix, if we take the time to figure out what it is that goes wrong with your restores. Understanding a problem before trying to solve it is always a good idea. (And, prevents doing crazy stuff like purging Postfix and reinstalling it from scratch…we don’t need to guess why your Postfix was a mess, that’s why. Any single problem in the Postfix configuration is easier to solve than every problem with the Postfix configuration because you started from scratch.)

Backup and restore is pretty reliable, lots of people do it every day with good results. If there’s a problem going from your particular old OS in the specific configuration you had to the new OS and the configuration you have now, it’s almost certainly minor and just needs you to compare the new and old systems to see why things went awry. It does not require blowing stuff up randomly and trying to reconstruct a working system from scratch.

1 Like

@Joe,

There’s more to the suggestion of a manual restore then was described above. I conducted a series of optimizations to his new install that a restore would not respect based on my experience.

As for Postfix it seems based on research into the matter which I was conducting while fixing things, that it was less configuration issues and more leaning towards permissions or incomplete install of either Postfix itself or third party scripts that corrupted Postfix.

Postfix was refusing to start, stop and restart via systemd, and journalctl was complaining about maildrop directory permission issues.

I read some suggestions from Postfix developer regarding correcting permissions, compared the install against another clients server running the same software stack (Debian 12 + Virtualmin) but after a few hours of working the situation it was going nowhere in the right direction.

The decision was then made to spin up a clean system and confirm the system was working.

So bottom line, there’s more to this then was originally described at midnight.

There are definitely different ways to address this, my suggestions are based on my experience migrating between systems, distros and between differently configured installs. Ideally if a bug in Virtualmin or the system is found I’d describe it here and/or suggest a path to resolution.