The technical part of a drive swap is the easy half. The hard half is a server that is down at 10 AM on a billing day because someone estimated 'about an hour' for a failing 2 TB drive. Planning is a skill — and it is learnable.
Every failed maintenance window I have seen failed the same way: the estimate assumed a healthy drive, the users were told a hopeful time, and there was no agreed moment to stop and roll back. A failing drive punishes all three habits. Estimate from the data, communicate wider than you hope, and fix the rollback deadline before you start.
Clone time is driven by how much must be read from a sick disk. A rough planning figure: a healthy drive copies at 100–150 MB/s, so 500 GB takes a little over an hour. A failing drive in its damaged regions may crawl at a tenth of that, and nobody can know in advance how much of the disk is damaged. The honest estimate is therefore a range with a fat tail: 'the copy itself is one to three hours; if the damage is worse than the SMART numbers suggest, it becomes five.' Plan the window around the bad end of the range — finishing early is a pleasant announcement; overrunning is a reputation.
Evenings after close and weekend mornings are the classic choices, but check the invisible users first: the backup job that runs at 21:00, the accounts package that posts at midnight, the owner who does reports from home on Sundays, the CCTV or billing system that talks to this server at night. A window that collides with an automated job fails even if every human agreed to it. The pre-check is five minutes: list what runs on or against this server in 24 hours, then place the window in the genuinely empty stretch.
Announcements that work contain exactly three things, sent to everyone (message group, notice, email — wherever this office actually reads):
The 'why' line matters more than it looks — people accept a planned four hours from the person who prevented an unplanned two days.
Decide, while calm, the latest time by which the new drive must pass its tests — say 21:30 in a window ending 22:00. If the clone is still crawling or the first boot fails at the deadline, the plan changes by rule, not by hope: reconnect the old drive, boot the known system, and reschedule with what you learned. The old drive, remember, still works — that is the entire luxury of rescuing early. A deadline agreed in advance protects you from the 1 AM logic of 'just one more setting', which is how a one-evening job becomes an all-night outage.
When the server is back, send the second message: 'Done. Server is running on the new drive; everything was tested. The old drive is kept safely for a week as a backup.' Then log the job somewhere durable: date, old drive model and serial, its final SMART numbers, new drive model, clone duration, any unreadable sectors reported. That log is next time's estimate — and the beginning of the monitoring habit that means the next failing drive is caught by a warning, not by a crash.
See the video for the hands-on half of this job — the clone itself, done in the safe order inside one planned window.
▶️ Watch Full VideoIt can, and for badly damaged drives it often must — but unattended means the morning can bring either a finished clone or a stalled one discovered hours late. If the drive's state allows, starting early evening with one check before you sleep beats a blind overnight run.
No. Files changing during a disk-to-disk copy produce an inconsistent copy — the offline clone this site recommends requires the server down and services stopped. 'Mostly idle' is not a state a database understands.
That is exactly the rollback-deadline question, answered in advance: if the deadline rule says stop, you stop — reconnect the old drive and reschedule, now knowing the true copy speed for a better second plan. An 80% clone is not 80% of a server; it is not a server at all.