In short: When switching from Windows to Linux, you think about programs, data and settings. That an external backup drive becomes a problem often only shows when you need it. My most important backup drive was encrypted with BitLocker and formatted with NTFS underneath. The data was readable, yet there were problems with the file system. My key lesson: diagnose first, then back up, and only then repair.

BitLocker and NTFS are two different things

BitLocker encrypts a drive. After unlocking, the actual file system appears underneath, in my case NTFS. This separation matters for troubleshooting. An error can occur in several places:

  • when unlocking the encryption
  • when mounting the drive
  • in the file system itself
  • only when writing

Being able to read the files is a good sign. But it doesn't prove that the file system is error-free or can be written to safely.

By the way, BitLocker drives can generally be unlocked on Linux, for example with cryptsetup, which supports BitLocker. In my case, though, unlocking was not the actual problem.

Please don't repair right away

A backup drive is the wrong place for experiments. Especially when important data is on it, you should record the current state before any repair.

On Linux, read-only commands help first:

lsblk -f
sudo blkid
findmnt
sudo dmesg | tail -n 50
  • lsblk -f shows the detected devices and file systems.
  • blkid helps identify drives unambiguously.
  • findmnt shows what is currently mounted.
  • The kernel log (dmesg) often contains hints about access problems.

Identifying the devices correctly is crucial. A wrong device address in a later write or repair command can be devastating.

What I took away from my case

My top priority was not to put the backup data at risk. So working read access mattered more to me at first than quick write access.

In the end my problem could be solved. But I wouldn't derive a general repair guide from it. Depending on the cause, very different steps are needed. With NTFS in particular, caution is advised if Windows didn't cleanly detach the drive before or if hibernation or fast startup information is still on it.

A note on ntfsfix: the tool only fixes some basic problems and is not a full replacement for the chkdsk file system check on Windows. If you use it, you should know what it changes and what it doesn't.

My backup concept after the switch

The incident showed me that encryption, file system and backup strategy have to fit together. A drive that only works reliably on the old operating system is not a good basis as your only backup.

Since then I pay attention to three things:

  • More than one copy: important data isn't kept in just one place.
  • A suitable file system: new backups get a file system that suits the devices I would need them on in an emergency.
  • Tested restores: a backup only counts once I can actually get the data back, including unlocking.

Conclusion

Switching to Linux doesn't end with the installation. Old drives and backups are part of the migration, just like the Docker environment.

My key insight: with an important backup, diagnose first, then back up, and only then repair. Readable files are valuable, but no reason for careless writes to a possibly damaged drive.

Frequently asked questions

Can Linux read BitLocker drives?

Yes, BitLocker drives can generally be unlocked on Linux, for example with cryptsetup. You need the password or the recovery key.

Is ntfsfix the same as chkdsk?

No. ntfsfix only fixes some basic problems. A thorough check of the NTFS file system is done by chkdsk on Windows.

What do I do first if a backup drive causes trouble?

Change nothing. First check the state with read-only commands, copy important data to another drive and only then think about repairing.

Tags:

Linux BitLocker NTFS Backup Data Security