Recommended setup for standby/mirror server after datacenter outage - is the native mirror the right

Hi everyone,

I'd like to ask for advice on the right architecture for a standby server. First some context, because it explains what I'm trying to protect against.

What happened

On July 2, 2026 · 06:27 PM my previous provider had a datacenter outage that left my server unreachable from the outside for more than 10 days. Their status page (https://status [dot] cloudcone [dot] com) has been showing the same incident since it started.

During those days I only had SSH access and access to port 8080 (ISPConfig), both with heavy latency — but nothing was reachable for clients: no HTTP/HTTPS, no mail. Around 26 websites and all mail accounts were down or intermittent for over a week. That limited access was at least enough to pull fresh, complete backups of everything.

I bought the Migration Toolkit to get everything out of there, but I couldn't use it: the old server had no outbound access to check the license.key, so the toolkit wouldn't run (https://forum.howtoforge.com/thread...unreachable-for-using-the-migrator-kit.95251/). I ended up migrating manually to a new server at a new provider (clean Debian 13 + ISPConfig auto-installer, 3.3.1p1). Everything is running fine there now.

What I want to build

I don't want to depend on a single provider again. I have a second server at a different provider (Debian 11, ISPConfig 3.3.1p1) which currently hosts a few small sites and acts as my secondary DNS. My plan:

• Empty that second server and reinstall it clean (Debian 13 + ISPConfig auto-installer, same stack as the main server), and turn it into a warm standby of the main server.
• If it's absolutely necessary, I could move the DNS (primary and secondary) outside both servers, to an external DNS provider with API and low TTLs, so the zones survive the loss of either machine — since changing DNS records is my failover mechanism.
• If the main server goes down: switch A/MX records to the standby, keep the critical clients online, and later sync back and return to the main server once it's up again.

To be clear about expectations: I'm fine with a manual failover, an RTO of about an hour is acceptable. I don't need automatic HA, floating IPs or keepalived — the two servers are at different providers, so that kind of setup doesn't apply anyway.

My questions

1. Is ISPConfig's native mirror (multiserver, "Is mirror of Server") the right feature for this? My concern: in a mirror setup the panel lives on the master — if the master is the machine that goes down, I'd have no panel to manage the standby, which is exactly the scenario I'm trying to cover. It also seems the mirror replicates configuration but not the actual data (web content, mailboxes, client DBs). That makes me think it's designed for redundancy within a cluster on the same network, not for independent failover between two providers.
   
   
2. If the mirror is not the right tool: is re-running the Migration Toolkit periodically against the same target a supported/recommended way to keep an independent standby in sync (config + sites + mail + DBs)? Would you complement it with direct rsync of /var/www and /var/vmail for more frequent syncs, or is that asking for trouble?
   
   
3. Sync back: after running on the standby for some days, what's the recommended way to merge changes back to the main server — especially mail that arrived on the standby in the meantime? Is imapsync / dovecot dsync per mailbox the usual approach, or is there something better integrated with ISPConfig?
   

Thanks a lot for any guidance. If it's useful I'm happy to report back and document the final setup, since this "independent warm standby between two providers" scenario doesn't seem well covered anywhere.

 

Firstly, I am not sure that this will work in order to mirror the ISPConfig main control panel web interface itself for failover, as this was written with the help of AI and I have not tested it myself.

However, I am quite certain that you cannot achieve this by using the internal ISPConfig Mirror setting alone, simply because it operates at the main system level.

The built-in mirror setting is strictly designed for replicating background services such as Apache, Postfix, and MariaDB, and although it is also available for DNS, it is generally preferred not to mirror DNS.

Because ISPConfig writes its configuration changes directly to the dbispconfig database on the Master server, achieving a mirrored panel interface requires replicating both the database and the ISPConfig web interface files at the system level.

The following idea might do the trick, although I have not personally tested it.

Step 1: Set up MySQL/MariaDB Master-Master Replication
The standby server's panel needs real-time access to the exact same database as the master, so I think this is essential.
1. Configure Master-Master (bidirectional) replication between the MariaDB databases of Server 1 (Master Panel) and Server 2 (Mirror / Standby Panel).
2. Ensure the dbispconfig database is synchronized instantly in both directions.
3. Ensure the auto_increment_increment and auto_increment_offset variables are configured uniquely on each server to prevent primary key conflicts.

Step 2: Install ISPConfig on the Mirror Server
1. Run the ISPConfig Auto Installer on your second (Mirror/Standby) server and during installation, choose to join the existing multiserver setup as a slave node.
2. Once installed, manually modify its local config.inc.php file (usually located in /usr/local/ispconfig/interface/lib/) so that it connects to its own local replicated database instead of the Master server's remote database.

Step 3: Synchronize the ISPConfig Interface Files
The interface files and themes should remain identical.
1. Set up a tool such as lsyncd or a cron-based rsync job to synchronize the interface directory from Server 1 to Server 2 (/usr/local/ispconfig/interface/).
2. Exclude config.inc.php from synchronization so that each panel retains its own local database connection settings.

Step 4: Configure Your Failover
You mentioned that you already have your own DNS failover method, so I assumed that has already a workout.

Again, I wrote this with AI's help and have not tested it, but after reading it several times, I think it should generally work.

My preference nowadays is virtualization with image-based backup and restore rather than manual intervention.

Others may chip in later with additional ideas, and hopefully, together you can find the solution that best suits you and your server requirements.

 

Thank you Till, this is extremely helpful — I didn't realise ISPCopy was part of the Migration Toolkit I already own. That changes things a lot, because keeping the ISPConfig config itself (vhosts, mailboxes, clients) in sync was exactly the part I had no clean answer for.

Two follow-ups:
1. ISPCopy + DB replication. Some clients work live on their sites, so I was planning MariaDB replication for the client databases. Can ISPCopy run for config + files only, skipping the databases, and let replication handle the data layer?

2. DNS. (Does ISPCopy sync this as well?)
This applies to both approaches and I can't resolve it: in a failover I need to change the A records to point to the standby, but the ISPConfig panel that manages my DNS lives on the server that just went down. Same with your snapshot approach — a new node gets a new IP, so I still need to edit DNS somewhere.

The only solution I found within ISPConfig is to invert the roles: standby as DNS master (its panel manages the zones), production server as secondary zone via AXFR/IXFR. Then the editable DNS panel sits on the machine that survives. Does that sound reasonable, or am I missing something simpler? How do you handle DNS in your own setup?

On your personal take - much appreciated. Hetzner was one of the two options I considered; I went with a smaller, cheaper provider to get my clients out of the outage fast. It does offer some of those cloud features, but I was only treating them as backups, not as a DR strategy.
I'll check whether they can restore a snapshot to a different datacenter — being a smaller hoster, I'm not sure they have more than one location, and that may be the real limit of that approach in my case. What I'm protecting against is losing an entire provider, not a single node: during the outage the machine was actually up, but the provider had nothing to move me to.

Thanks again.

 

To be honest, it sounds more complicated to build the setup as a warm standby. Why not keep both systems active at all times and use a standard mirror setup instead? In that case the only thing you'd need to handle yourself is the mail synchronization and DNS failover, which isn't that complex.

The failover approach also requires you to manually test the failover from time to time to ensure it still works as expected and that nothing breaks. Or am I missing something here?