On a plain file server, a clone boots and life goes on. On a domain controller or a database server, the same clone booted carelessly can poison your whole network — quietly, and in ways that surface weeks later.
A clone is an identical twin: same name, same IP, same machine identity, same database contents at the moment of copying. That identity is exactly what you want on the new drive — and exactly what makes two copies alive at once dangerous, and a live database copied mid-write unreliable. This page is the caution list the plain clone guides skip.
Both drives carry the same computer name, the same IP address and the same machine SID. Boot the clone while the old drive's system is also running — or worse, put the old drive into another machine and boot it — and the network sees one identity in two places: name conflicts, broken secure channels, users authenticated by a ghost. The rule is absolute: the first boot of the clone happens with the old drive disconnected, and the old drive is never booted on the network again. It is a fallback disk now, to be attached only as a data drive (not booted) if you must pull a file from it, or wiped.
Active Directory tracks changes with update sequence numbers (USNs). If a domain controller is restored from an old copy — which is exactly what a clone of last Tuesday's drive is — it can rejoin the domain believing its database is current when it is actually behind. Other DCs then refuse its changes and you get USN rollback: lingering objects, mismatched passwords, replication quietly broken. Modern Windows Server versions detect improper restores on virtual platforms, but a raw disk clone is not a supported DC backup for a reason.
The safe pattern for a DC with a failing drive: if the domain has another healthy DC, the cleanest rescue is often to let the sick DC go, build fresh, and promote a new DC that replicates in — no clone at all. If it is the only DC, clone it offline, boot the clone alone, and immediately check replication and the Directory Service event log; treat any USN or lingering-object errors as a stop-and-think moment, not noise. And whatever you do, never bring the old DC drive back online 'just to check something'.
SQL Server, MySQL, Tally-type accounting systems and mail stores all keep part of their data in memory and write it to disk in pieces. A clone taken while the service runs captures the disk mid-sentence: the copied database may open fine, open with errors, or — worst — open and quietly contain a half-applied transaction. You cannot tell from the clone's progress bar.
After the first boot on the new drive, open the application and verify recent records — the last invoices, the last day's entries — against what users expect. That check is the real consistency test.
A clone carries the machine's activation, but swapping hardware around it can still trigger Windows or application re-activation prompts on some setups — have the licence keys reachable before the window, not during it. Scheduled tasks and backup jobs also clone faithfully and will start firing on the new drive on schedule: that is what you want, but check the backup destination paths still make sense, and make sure the old drive's copy of the server never runs its jobs again (it cannot, if it never boots again — another reason for the rule in step 1). Also expect IP-based allowlists elsewhere — printers, firewalls, other servers that trusted this machine by IP — to keep working, since the IP does not change.
Before users are invited back, walk the list that proves the twin is the real server now:
The video performs the clone with the server properly shut down and services handled first — the order this page explains.
▶️ Watch Full VideoNo. Microsoft's supported routes are Windows Server Backup / System State backups and virtualisation snapshots with VM-Generation ID safeguards. A clone is a hardware-rescue technique for a failing drive — used offline, booted alone, and verified immediately, it works; treated as a routine backup it will eventually bite.
If the clone boots alone with the same name and IP, users should notice nothing at all — same shares, same permissions, same logons. That invisibility is precisely why the old copy must never come back online: the network cannot tell the twins apart either.
Opening is a good sign, not a guarantee. Verify the most recent transactions against reality (last entries, today's invoices, stock figures) and run the database's own consistency check if it has one — for SQL Server, that is a DBCC CHECKDB in your next maintenance window.