NTFS Partition is "mountable" but Backup Falls to RAW
A partition and disk imaging/cloning program
Brought to you by:
steven_shiau
Menu
▾
▴
There is a "new to me" server that I need to be able to back up. It has 2 drives, one is about 240GB and one is about 960GB. They both have NTFS partitions.
The 240GB drive backs up without any issue, as expected.
The 960GB volume CloneZilla 3.2.2-15 always tries to back up as raw.
If I drop to the shell, I can use "mount.ntfs" and mount the 960GB volume without issue. So, I don't think there's an issue with the format/partition table. I've attached a screenshot of the parted 'print' output for both drives. I don't see anything that stands out as a potential issue.
Is there anything else I can look at to troubleshoot why there may be an issue. I tried setting the backup priority to the default (partclone) and the option for ntfsclone, both resulted in it falling back to "RAW", but I don't see where I can figure out "why" it decided to use RAW.
Last edit: Russ Kubes 2025-09-11
I also tried dropping to shell and running:
partclone.ntfs -c -s /dev/sda1 -o ./testThis executed successfully and backed up the contents of the partition. So, it seems partclone is able to back it up, but for some reason Clonezilla doesn't think it can.
Edit:
My apologies, I was able to find the Clonezilla log.
I see that the drive was detected as a VMFS_Member. It is true that this drive used to be in an ESXi instance, it had since been reformatted to NTFS.
VMFS6 Tools correctly identifies that it's not a VMFS drive anymore. mount.ntfs and partclone both correctly identify that it is an NTFS drive now. However, something is left behind that's still making Clonezilla think it's a VMFS drive and failing to clone it.
I'm most likely going to see if I can just back up the data manually (it's only a few hundred MB in use at the moment), then rewiping the drive to see if I can clear the old VMFS tags (wherever they are).
Edit 2:
I was able to use 'wipefs' to just remove the VMFS tag from the GPT partition table. I first ran the command without parameters to confirm it was there, and the drive had both a tag for NTFS at offset 0x3 and a tag for VMFS_volume_member at offset 0x100000. Of course, in reality there is only an NTFS partition.
I ran the following command to clear it:
You can add the "-n" option first to do a dry run.
After I ran this command, I needed to boot back into Windows - because Clonezilla was complaining the disk was "dirty" and "ntfsfix" wasn't detecting any issues. After booting into Windows, and then rebooting back to Clonezilla, I was able to successfully back up the drive.
Again, since it's only a few hundred MB of data in my case, I'm going to go ahead and rebuild that drive from a fresh wipe anyway - just to be extra safe that there's no other abnormalities in the GPT table or in the filesystem.
Last edit: Russ Kubes 2025-09-12
Great. Thanks for sharing that. So when your /dev/sdb1 was formatted as NTFS, some metadata in the file system was not wiped so it still contains the VMFS headers...
Yes, that's what it looks like. I was given the machine second hand so I don't know the full process they used when they converted it. The VMFS tools knew enough that it wasn't VMFS. Parted knew it was NTFS. Even ntfsfix and mount.ntfs had no problem with it. It just seemed the generic "mount" command was getting confused by the left over metadata and couldn't mount it. That's the component that was still identifying it as VMFS volume member.
Since I removed that signature, I no longer have an issue.