Input DRSite: a Plesk extension for backup and automatic failover. Looking for 2 pilot hosts (free)

[drsite]

Server operating system version

AlmaLinux 9

Plesk version and microupdate number

18.0.x

If you run Plesk and a server dies, your customers are offline until you restore. We built DRSite to fix that for our own hosting: each site has a tested standby copy on a second server, and DNS switches over automatically when the main server is down. It also keeps backups in a vault that can't be deleted, in case of ransomware.

It's been running on our own servers for internal use. Now we want two hosts outside our company to run it in production and tell us what breaks.

What you get: free for 3 months, setup help from me directly.
What we ask: run it on at least one production server, and give honest feedback.

It's a Plesk extension that installs from a signed package we send you.

DM me or reply.

 

[Kaspar]

That sounds like an interesting concept.

Can you share some additional details on how this works exactly? For example what are the requirements for the second server? Is it real time replication or is data synced periodically? What are the DNS requirements for this setup?

 

[Bitpalast]

First of all, @drsite thank you for taking on this challenge! You're addressing one of the longest-standing and most difficult problems in the Plesk hosting environment, and I genuinely appreciate the effort you're putting into finding a practical solution.

Some years ago, Alexander @AYamshanov developed an extraordinarily sophisticated and meticulously engineered high-availability cluster for Plesk. His work was a remarkable technical achievement, exceptionally well thought through and, in my opinion, one of the most impressive engineering projects ever undertaken in the Plesk ecosystem. For anyone interested, here is his excellent work: How to Install Plesk in a High Availability Cluster - Plesk

Despite my admiration for Alexander's outstanding solution, I was left with the impression that the inherent complexity of such a setup would make it difficult to deploy and maintain economically in everyday hosting operations. That certainly wasn't a shortcoming of his work, but rather a reflection of just how challenging this problem really is.

Perhaps a replication-based approach could offer a more practical alternative. However, particularly on larger servers, keeping a standby system continuously synchronized presents considerable challenges. Replicating the exact state of potentially millions of files quickly enough is anything but trivial. And the operating costs go well beyond additional hardware and licenses: ongoing administration, monitoring, maintenance, and troubleshooting can easily make such a solution economically unattractive.

I've long wished for a reliable, affordable, and manageable solution to this problem. Even after studying Alexander's exceptional work, I couldn't quite see how to make the economics work for everyday hosting.

That's precisely why I'm delighted to see someone approaching this challenge from a fresh angle. If DRSite can overcome even some of these obstacles while keeping deployment and maintenance straightforward, it could be a genuinely valuable contribution to the Plesk community.

I sincerely wish you every success with this project and look forward to seeing how it develops!

 

[drsite]

That sounds like an interesting concept.

Can you share some additional details on how this works exactly? For example what are the requirements for the second server? Is it real time replication or is data synced periodically? What are the DNS requirements for this setup?

First of all, @drsite thank you for taking on this challenge! You're addressing one of the longest-standing and most difficult problems in the Plesk hosting environment, and I genuinely appreciate the effort you're putting into finding a practical solution.

Some years ago, Alexander @AYamshanov developed an extraordinarily sophisticated and meticulously engineered high-availability cluster for Plesk. His work was a remarkable technical achievement, exceptionally well thought through and, in my opinion, one of the most impressive engineering projects ever undertaken in the Plesk ecosystem. For anyone interested, here is his excellent work: How to Install Plesk in a High Availability Cluster - Plesk

Despite my admiration for Alexander's outstanding solution, I was left with the impression that the inherent complexity of such a setup would make it difficult to deploy and maintain economically in everyday hosting operations. That certainly wasn't a shortcoming of his work, but rather a reflection of just how challenging this problem really is.

Perhaps a replication-based approach could offer a more practical alternative. However, particularly on larger servers, keeping a standby system continuously synchronized presents considerable challenges. Replicating the exact state of potentially millions of files quickly enough is anything but trivial. And the operating costs go well beyond additional hardware and licenses: ongoing administration, monitoring, maintenance, and troubleshooting can easily make such a solution economically unattractive.

I've long wished for a reliable, affordable, and manageable solution to this problem. Even after studying Alexander's exceptional work, I couldn't quite see how to make the economics work for everyday hosting.

That's precisely why I'm delighted to see someone approaching this challenge from a fresh angle. If DRSite can overcome even some of these obstacles while keeping deployment and maintenance straightforward, it could be a genuinely valuable contribution to the Plesk community.

I sincerely wish you every success with this project and look forward to seeing how it develops!

Thank you, that's kind of you, and Alexander's cluster is impressive work.

DRSite deliberately takes the other side of that trade-off. It isn't a high-availability cluster and doesn't try to keep a second server in step file by file. It's disaster recovery: each site is restored on a standby from Plesk's own backups (full, then incrementals), so there's no shared storage and no live replication to babysit. The cost is a recovery point of minutes to a day rather than zero, which we think is the right trade for most hosting customers.

It also works per site, not per server. You choose which sites get a standby, and a standby server can hold copies from several primaries, so you aren't doubling every server.

We're running it with a small number of pilot hosts first. If you'd like to try it, send me a DM.

 

[drsite]

That sounds like an interesting concept.

Can you share some additional details on how this works exactly? For example what are the requirements for the second server? Is it real time replication or is data synced periodically? What are the DNS requirements for this setup?

Thank you! In short:

- Second server: a Plesk server running the same extension. It can be one of ours, so you don't need extra hardware, or one of your own.
- Sync: periodic, not real-time. It's built from Plesk's own backups, every 15 minutes up to daily depending on the plan.
- DNS: our DNS, Cloudflare, or your own Plesk DNS with a secondary. Failover repoints the A and MX records.

We're still in the pilot stage, so I'd rather go through the details one to one. If you'd like to be one of the pilot hosts, send me a DM and I'll walk you through it.