I'm a recent graduate working on the web development team at a medical clinic. Our small IT department supports internal patient-record systems, HR tools, appointment systems, and on-site hardware. The applications are mostly legacy vanilla PHP running on Apache with FastCGI, currently hosted on an i9 gaming PC that handles roughly 16 requests per second and peaks around 400 concurrent users.
These systems support critical business processes and need to remain available around the clock. We may purchase an HP ProLiant server, and I'm considering a migration plan involving a three-node Proxmox cluster: the new server, the existing machine, and a small witness node. The main PHP applications would run in virtual machines, while MySQL would run in containers. I was also considering ZFS pools on both main nodes with continuous replication, plus an Nginx reverse proxy for routing.
I realize this is ambitious for someone early in their career, so I'm looking for a sanity check. What major operational, security, compliance, backup, and disaster-recovery risks should we address before attempting this migration? Would asynchronous ZFS replication provide sufficiently fast and reliable failover for MySQL, or would a different database and storage architecture be more appropriate?
4 Answers
Backups and recovery are more important than simply adding a cluster. Plan for encrypted, automated backups with immutable and off-site copies, separate backup credentials, regular restore tests, and a documented disaster-recovery procedure. A replica is not a backup because corruption, accidental deletion, ransomware, or application errors can be replicated too.
You’ll also need access controls, audit logging, encryption in transit and at rest, network segmentation, patch and vulnerability management, monitoring, alerting, asset documentation, change control, and tested recovery procedures. Confirm the clinic’s legal and compliance obligations with its privacy and security staff before moving patient data.
ZFS replication is asynchronous. If replication runs every minute, a host failure can lose every database write made since the last successful replication. Proxmox may restart a virtual machine elsewhere, but it cannot recover data that was never copied.
Define the required recovery point objective first. If the business truly needs zero or near-zero data loss, asynchronous storage replication alone is not enough. Database-level replication or a properly designed synchronous storage solution may be needed, and both require careful testing. Also, failing over from an enterprise server to a gaming PC does not provide meaningful hardware redundancy; both production nodes should have reliable power, ECC memory, RAID or equivalent protection, redundant components, and vendor support.
This should be treated as a healthcare infrastructure project, not just a virtualization upgrade. A home lab and web-development experience are useful for learning, but they are not enough preparation to design production high availability for systems that could affect patient care.
Bring in an experienced healthcare infrastructure consultant, managed service provider, or qualified systems integrator. Have them work with your team on requirements, architecture, migration testing, security controls, documentation, and a rollback plan. Use the project as a learning opportunity, but don’t make a junior employee solely responsible for the production design.
Keep the design as simple as possible and establish priorities with management. Data correctness should come before availability, followed by recovery time and performance. Don’t assume that containers, clustered virtualization, or shared storage automatically improve reliability; each adds operational complexity and another failure mode.
Get an approved maintenance window, test the migration with representative data, measure application and database behavior under failure, and have a tested rollback path. If management requires continuous availability and near-zero data loss, that requirement needs an appropriate budget and support model rather than relying on an improvised cluster.
The proposal is still valuable as a tabletop exercise. The important distinction is testing the design in a lab versus deploying it directly against live clinical workflows.