I accidentally ran the Diskpart clean command on a GPT drive and now the partitions are gone. I need help figuring out if the partition table and data can be recovered safely without making things worse.
First thing: stop using that drive right now. Don’t copy anything to it, don’t format it, don’t run Diskpart commands, and don’t let Windows “fix” it. If it’s your main system disk, power down and boot from a live USB instead. If it’s an external or second drive, unplug it or unmount it until you’re ready to recover it.
A missing GPT partition is scary, but it’s not automatically game over. GPT disks have a bit of an advantage over old MBR disks because GPT stores a backup partition header at the end of the drive. So if the front part of the partition table got damaged, there may still be enough information left to work with.
If you have another drive with enough free space, make a full sector-by-sector image before doing anything else. Tools like dd or ddrescue are good for this if you’re comfortable in the terminal. Some paid imaging tools can do it too. The point is simple: try recovery on a copy, not the only disk that has your data on it.
For most people, recovery software is the easier path. When the partition table is damaged, the OS may act like everything is gone, but the actual files are often still sitting there until something overwrites them.
Disk Drill is a solid option for this kind of situation. It can scan the whole physical drive instead of relying on the broken partition entry, then look for lost partitions and file system signatures. It also lets you preview files before recovering them, which helps you avoid wasting time pulling back junk or incomplete data. It works with common file systems like NTFS, FAT32, and exFAT, and it can also scan drives that show up as RAW.
The basic flow is usually:
- Select the physical disk, not just a missing or broken volume.
- Run the lost data scan.
- Check the Existing and Reconstructed sections.
- Recover the files to a different drive. Do not save them back to the damaged one.
If you want to try repairing the partition layout instead of just copying files out, look at TestDisk or gdisk. TestDisk can scan for old partition signatures and, if everything lines up, write the partition entries back. The scan itself is fine, but the “Write” step changes the disk, so don’t do that unless you’re sure the found partition looks right.
gdisk is also worth knowing about for GPT-specific problems. Since GPT keeps a backup header at the end of the disk, gdisk can sometimes rebuild the primary header from that backup. That can help when the damage is mostly near the beginning of the drive.
One more thing: if Windows shows the drive as a “GPT Protective Partition,” don’t immediately run Diskpart clean or convert it to MBR. That label can show up after a weird hardware change, like moving a drive from a USB dock to SATA, or because of a sector-size mismatch or driver issue. Running clean wipes the partition table, which is exactly what you don’t want before recovering the files.
So the safer order is: stop writing to the disk, image it if possible, recover files to another drive, and only then think about repairing or rebuilding the partition table.
Do not click “Initialize” in Disk Management just to see what happens. That is the kind of small harmless-looking step that can turn a recoverable partition table problem into a messier recovery job.
The big question is whether you ran clean or clean all. Plain clean usually removes the partition metadata, so the files may still be sitting there. clean all writes zeros across the disk, and at that point normal partition recovery is basically not realistic. If you are not 100% sure which one you used, treat the drive as recoverable but fragile until proven otherwise.
I agree with the advice to image the disk first, but I’d be careful about “repairing” before you know what was found. A tool may detect several old or partial partitions, especially on drives that were reused. Picking the wrong one and writing it back can make Windows mount the wrong layout or prompt for formatting. If the data matters, scan first and copy files to another disk. Disk Drill or similar tools are fine for that part because they let you recover files without committing a new partition table to the damaged drive.
Only after your important files are copied somewhere else would I try rebuilding the GPT. If this was a boot drive, don’t expect restoring the partition entry alone to make it boot cleanly again. EFI partitions, recovery partitions, BitLocker, and drive letter confusion can all add extra work. File recovery first, partition repair second.
The backup GPT is not something I’d count on after diskpart clean. GPT does keep a backup header at the end of the disk, but Diskpart’s clean is specifically meant to remove the disk layout, and in practice you should assume both the front and backup GPT metadata may be gone or unreliable. If a tool happens to find usable GPT backup data, great, but don’t build the whole plan around that.
The safer assumption is: the partition map is gone, the file contents may still be there, and your job is to avoid giving Windows any reason to write a fresh layout over the evidence.
A detail people often miss is sector alignment and exact partition boundaries. If this was a Windows GPT disk, the main NTFS partition probably started at a common offset, but “probably” is not good enough if the drive had several partitions, was cloned before, had OEM recovery partitions, or was resized. Recovery tools may show multiple possible NTFS starts. The correct one is usually the one where the file tree looks sane: normal folder names, expected dates, expected files, not a pile of random fragments.
I would not start by trying to make the disk mountable again. Mountable is not the same as recovered. Windows is very eager to “help” once it sees a damaged volume, and that help may include chkdsk, formatting prompts, or writing new metadata. If you rebuild the wrong partition entry and then Windows runs repairs on it, you can make a clean file recovery harder.
My order would be:
- Disconnect the drive or make it read-only if you know how.
- Make a full image to another disk if the data is important enough to justify the time.
- Scan the image or the physical disk in read-only mode.
- Recover the files you actually care about to a different drive.
- Only after that, experiment with restoring the partition table.
Disk Drill is fine for the “copy my files out” stage, especially if you want a GUI and previews. I would treat it like an extraction tool, not a magic undo button. Same with TestDisk: scanning is harmless enough, but writing the found partition table is the point where you can shoot yourself in the foot.
BitLocker is another catch. If this was a BitLocker-protected Windows disk, a normal scan may look disappointing or weird until the volume is identified and unlocked with the recovery key. Don’t assume “no filenames found” means the data is gone. It may just mean you are looking at encrypted content. Keep the recovery key handy before you start trying fixes.
If this is an SSD, keep expectations a little lower than with a hard drive. The clean command itself is not the same as clean all, but SSDs, TRIM, encryption, and controller behavior can change the practical outcome. That is another reason to stop booting from it or leaving it attached to a running Windows install.
So yes, recovery is possible after plain clean, but the least risky version is not “restore GPT and hope.” It is “get the files off first, then worry about making the original disk pretty again.”
