I just started an IT role at a dealership and discovered an extremely fragile environment. There are roughly 60 workstations, ranging from Windows 8.1 to Windows 10, along with several printers. Some machines use Active Directory managed by an IBM server running Windows Server 2008, while others are outside the domain. There are also several headless Windows machines being used as file servers, a completely flat network, two DVRs instead of proper NVRs, and a FortiGate firewall facing the internet.
The biggest concern is that the dealership's primary data is stored on a single 1 TB SATA hard drive inside one headless Windows PC. That machine hosts the Tally server, file shares, and an Apache-based site containing purchase information. There are currently no backups, redundancy, or apparent disaster-recovery plan. All systems are shut down after business hours, and many Windows installations appear to be unauthorized or obtained from untrusted sources.
The previous administrator is leaving and had already warned management that the infrastructure needs major investment. Management considers IT a basic utility and is reluctant to approve spending. I'm worried that one disk failure, malware incident, or hardware problem could bring the business down and that I'll eventually be blamed.
My initial idea was to reuse an older server, install Proxmox, run a newer Windows Server virtual machine for Active Directory, migrate away from Server 2008, and use a Debian-based VM to consolidate the scattered file servers. I was also considering mergerfs and SnapRAID for storage protection. Is this a reasonable starting point, or should I approach the situation differently?
5 Answers
Your first priority is not Proxmox, network segmentation, or migrating Active Directory—it is getting verified backups. Make an inventory, identify the truly critical data, and create at least one offline or off-site copy. Then test restoring it. A backup that has never been restored is only a hope.
After that, document every major risk: the unsupported operating systems, unlicensed software, single-disk database, lack of redundancy, flat network, and shutdown procedure. Give management a written list with practical remediation options, estimated costs, expected downtime, and the business impact of losing the system. Keep their responses and any declined recommendations in writing.
If leadership approves a real budget, this could become a valuable modernization project. If they only want you to keep the current setup running for free, it is a trap. The previous administrator’s warnings are strong evidence that the technical problem is also a management problem, so make sure you understand the expectations, authority, and compensation before committing to a large transformation.
You need management buy-in before trying to rescue this place. Explain the situation in business terms: how long sales and service operations can continue if the database disappears, how much data recovery might cost, and what a day of downtime means in lost revenue. Present a phased plan with an emergency backup phase, a stabilization phase, and a modernization phase.
If they still refuse to spend money or accept the risks, the environment is not realistically fixable. You can maintain it temporarily, but you cannot provide reliability that the business refuses to purchase.
A dramatic test outage probably is not worth the risk. A clear written report, recovery quote, and realistic downtime estimate should be enough to show the consequences without putting production data in danger.
Start looking for another job now. This is the kind of environment where the administrator is expected to prevent every failure without being given the tools or budget to do so. When the single drive, old server, or compromised workstation finally fails, you may be treated as responsible even though the risks existed before you arrived.
You can still do useful work while you search: document the environment, protect the critical data as safely as possible, and make reasonable recommendations. Just do not take ownership of risks that management has explicitly chosen to accept, and do not make major changes without a rollback plan and written approval.
The virtualization plan is technically plausible, but it does not solve the main problem if management will not fund hardware, licenses, storage, backup software, and support. Do not assume SnapRAID or mergerfs automatically makes business data safe; they are not a substitute for tested backups, and the old hardware may fail during the migration.
A sensible long-term design could include supported operating systems, separate domain and application roles, reliable storage with redundancy, network segmentation, firewall maintenance, endpoint protection, and cloud or off-site backups. But the design should follow a risk assessment and the applications’ requirements—not just whatever old server happens to be available.
I would also take an image or full backup of the existing critical server before making significant changes. Migrating a fragile system without a rollback plan can turn a bad situation into an immediate outage.