Advice Request Backing up Windows 11 with Bitlocker enabled.

[Divine_Barakah]

Hello,


I am using AOMEI Backupper Pro on Windows 11 and when I create a full system back and then restore it, Bitlocker gets disabled and system is restored in an unencrypted state. Bitlocker needs to be reenabled and it takes much time.


It would be great if other members here share their experience with Bitlocker and system imaging tools.

 

[Bot]

Hello,


I am using AOMEI Backupper Pro on Windows 11 and when I create a full system back and then restore it, Bitlocker gets disabled and system is restored in an unencrypted state. Bitlocker needs to be reenabled and it takes much time.


It would be great if other members here share their experience with Bitlocker and system imaging tools.

You’ve run into a fairly common side effect of using third‑party imaging with BitLocker: most tools restore the data, but not the encryption state.

Why BitLocker gets disabled after restore
In general, imaging tools handle BitLocker system drives in one of two ways:

• “Intelligent”/file‑level style imaging: The tool uses VSS to read the decrypted contents of the volume and stores that in the image.
  On restore, it creates a normal NTFS partition and writes the data back. Result: system works, but the volume is no longer BitLocker‑encrypted, so you must turn BitLocker on again and wait for re‑encryption.
  
• Sector‑by‑sector (forensic) imaging: The tool copies every sector, including BitLocker metadata and ciphertext, without understanding the filesystem.
  On restore, you usually get the original BitLocker‑encrypted volume back as‑is. Downsides: images are bigger and slower to create/restore.

From what’s described (and from what AOMEI has documented in the past), AOMEI Backupper’s normal/full system backup behaves like the first method. So what you’re seeing is expected behavior for that mode.

Experiences with other tools (in general)
Without speaking for specific members here, typical behavior across common tools tends to be:

• Many third‑party imaging tools (including several popular ones) back up BitLocker volumes in decrypted form and restore them as unencrypted NTFS. BitLocker must be turned back on and the drive re‑encrypted after restore.
• Some tools offer a “sector‑by‑sector” / “forensic” / “clone all sectors” option that can preserve BitLocker as‑is, but:
  • Images are as large as the used space (or entire disk, depending on implementation).
  • Backups and restores are significantly slower.
  • Not every product supports this for system disks, and there may be restrictions on restoring to disks of different sizes.
• Windows built‑in tools: Behavior has changed between Windows versions and tools (old “System Image Backup”, wbadmin, etc.). Some workflows still require you to re‑enable BitLocker manually after bare‑metal restore. I wouldn’t rely on them to “magically” preserve encryption unless confirmed in current Microsoft docs for your exact method.

So what you’re seeing with AOMEI is not unusual. It’s more a design choice than a bug.

What you can try with AOMEI Backupper
A few practical approaches (you’d have to check AOMEI’s current docs/options for your version):

• Check for sector‑by‑sector options:
  Look whether there is a “sector by sector backup/clone” or similar option for the system drive. If available and supported for your scenario:
  • Create an image with that mode.
  • Restore and then check BitLocker state (manage-bde -status).
  If BitLocker stays enabled, you’ve solved the re‑encryption problem at the cost of larger/slower backups. If not, then the product simply doesn’t support preserving the encrypted state.
  
• Accept re‑encryption but optimize the process:
  • Always make sure you have your BitLocker recovery key backed up before experimenting.
  • After every full restore, plan to turn BitLocker on immediately and leave the system idle so it can encrypt as fast as possible.
  • If you have an SSD and CPU with AES‑NI, encryption speed is often quite acceptable; it’s mostly a time‑planning issue.
• Use a different strategy for frequent restores:
  If you do very frequent test‑restores or “lab” work, some people:
  • Keep the test OS image unencrypted, but encrypt only the data partitions that matter.
  • Or use a VM for testing and keep BitLocker only on the host.
  Obviously, this is a trade‑off vs. security, so not ideal for your main daily‑driver install.

What I’d suggest next

• Check AOMEI’s documentation or support for your specific version to see if they explicitly mention BitLocker behavior on restore.
• Experiment once with any “sector‑by‑sector” or equivalent mode (if present) to see whether it preserves encryption for you.
• If preserving BitLocker state is critical and your current tool can’t do that, you might want to test an alternative imaging solution in a non‑production scenario and see how it behaves with BitLocker on your hardware.

Hopefully other members will chime in with which imaging tools they use with BitLocker, and whether their restores come back encrypted or require full re‑encryption each time.

 

[Divine_Barakah]

You’ve run into a fairly common side effect of using third‑party imaging with BitLocker: most tools restore the data, but not the encryption state.

Why BitLocker gets disabled after restore
In general, imaging tools handle BitLocker system drives in one of two ways:

• “Intelligent”/file‑level style imaging: The tool uses VSS to read the decrypted contents of the volume and stores that in the image.
  On restore, it creates a normal NTFS partition and writes the data back. Result: system works, but the volume is no longer BitLocker‑encrypted, so you must turn BitLocker on again and wait for re‑encryption.
• Sector‑by‑sector (forensic) imaging: The tool copies every sector, including BitLocker metadata and ciphertext, without understanding the filesystem.
  On restore, you usually get the original BitLocker‑encrypted volume back as‑is. Downsides: images are bigger and slower to create/restore.

From what’s described (and from what AOMEI has documented in the past), AOMEI Backupper’s normal/full system backup behaves like the first method. So what you’re seeing is expected behavior for that mode.

Experiences with other tools (in general)
Without speaking for specific members here, typical behavior across common tools tends to be:

• Many third‑party imaging tools (including several popular ones) back up BitLocker volumes in decrypted form and restore them as unencrypted NTFS. BitLocker must be turned back on and the drive re‑encrypted after restore.
• Some toolsoffer a “sector‑by‑sector” / “forensic” / “clone all sectors” option that can preserve BitLocker as‑is, but:
  • Images are as large as the used space (or entire disk, depending on implementation).
  • Backups and restores are significantly slower.
  • Not every product supports this for system disks, and there may be restrictions on restoring to disks of different sizes.
• Windows built‑in tools: Behavior has changed between Windows versions and tools (old “System Image Backup”, wbadmin, etc.). Some workflows still require you to re‑enable BitLocker manually after bare‑metal restore. I wouldn’t rely on them to “magically” preserve encryption unless confirmed in current Microsoft docs for your exact method.

So what you’re seeing with AOMEI is not unusual. It’s more a design choice than a bug.

What you can try with AOMEI Backupper
A few practical approaches (you’d have to check AOMEI’s current docs/options for your version):

• Check for sector‑by‑sector options:
  Look whether there is a “sector by sector backup/clone” or similar option for the system drive. If available and supported for your scenario:
  • Create an image with that mode.
  • Restore and then check BitLocker state (manage-bde -status).
  If BitLocker stays enabled, you’ve solved the re‑encryption problem at the cost of larger/slower backups. If not, then the product simply doesn’t support preserving the encrypted state.
• Accept re‑encryption but optimize the process:
  • Always make sure you have your BitLocker recovery key backed up before experimenting.
  • After every full restore, plan to turn BitLocker on immediately and leave the system idle so it can encrypt as fast as possible.
  • If you have an SSD and CPU with AES‑NI, encryption speed is often quite acceptable; it’s mostly a time‑planning issue.
• Use a different strategy for frequent restores:
  If you do very frequent test‑restores or “lab” work, some people:
  • Keep the test OS image unencrypted, but encrypt only the data partitions that matter.
  • Or use a VM for testing and keep BitLocker only on the host.
  Obviously, this is a trade‑off vs. security, so not ideal for your main daily‑driver install.

What I’d suggest next

• Check AOMEI’s documentation or support for your specific version to see if they explicitly mention BitLocker behavior on restore.
• Experiment once with any “sector‑by‑sector” or equivalent mode (if present) to see whether it preserves encryption for you.
• If preserving BitLocker state is critical and your current tool can’t do that, you might want to test an alternative imaging solution in a non‑production scenario and see how it behaves with BitLocker on your hardware.

Hopefully other members will chime in with which imaging tools they use with BitLocker, and whether their restores come back encrypted or require full re‑encryption each time.

That's what I expected. I believe the only way to preserve Bitlocker and the encryption status is by using sector-by-sector backup, but unfortunately that results in a huge backup size and when restored it causes unwanted writes on the SSD.

Any idea what is best to use VSS or AOMEI Backup service to backup the system? Any major differences or benefits?

 

[Bot]

That's what I expected. I believe the only way to preserve Bitlocker and the encryption status is by using sector-by-sector backup, but unfortunately that results in a huge backup size and when restored it causes unwanted writes on the SSD.

Any idea what is best to use VSS or AOMEI Backup service to backup the system? Any major differences or benefits?

You’re right about sector‑by‑sector: it’s usually the only way to truly “preserve” BitLocker as‑is, and it does mean bigger images and more writes.

For your second question:

VSS vs AOMEI Backup Service – what’s the difference?

In AOMEI, these options control how the program takes a snapshot of a live/online system so it can back up open files:

• Microsoft VSS (Volume Shadow Copy Service)
  • This is the built‑in Windows snapshot mechanism.
  • Many applications (databases, mail servers, etc.) are VSS‑aware and know how to quiesce/flush data when a VSS snapshot is created.
  • It’s generally the most compatible and safest option for system backups, because it’s what Windows and most backup tools are designed around.
  • If VSS on the system is broken (common after some software/uninstalls), you may get snapshot or “shadow copy” errors.
• AOMEI Backup Service
  • This is AOMEI’s own snapshot mechanism, used as an alternative when VSS doesn’t work properly.
  • It can sometimes succeed where VSS fails (e.g. messed‑up VSS writers, odd conflicts).
  • However, many applications are not specifically aware of it, so you don’t get app‑level coordination like VSS writers provide.
  • For a typical home/desktop system (no critical databases running), it usually works fine, but it’s less “standard” than VSS.

Which should you use?

Short version:

• Use VSS as the default if it works reliably on your system.
• Use AOMEI Backup Service only if:
  • VSS fails to create snapshots, or
  • Backups regularly error out with VSS/shadow copy related messages.

For a normal Windows 11 machine with BitLocker, there’s no meaningful difference for BitLocker itself: in both cases, AOMEI is backing up the decrypted contents of the volume. So:

• Encryption state will still be lost on restore (as you’ve seen).
• Switching between VSS and AOMEI Backup Service won’t change that behavior.

Practical suggestion

• Stick with VSS unless you have specific snapshot errors.
• If you ever start seeing VSS errors, test a backup once with AOMEI Backup Service to see if it resolves them.
• Regardless of which you use, occasionally test a restore (to a spare disk, VM, or non‑critical system) to ensure the images are actually bootable and consistent.

So for your setup: keep using VSS as long as it behaves; it’s the more standard and better‑integrated choice in Windows. The BitLocker issue unfortunately won’t change with that setting.

 

[Divine_Barakah]

You’re right about sector‑by‑sector: it’s usually the only way to truly “preserve” BitLocker as‑is, and it does mean bigger images and more writes.

For your second question:

VSS vs AOMEI Backup Service – what’s the difference?

In AOMEI, these options control how the program takes a snapshot of a live/online system so it can back up open files:

• Microsoft VSS (Volume Shadow Copy Service)
  • This is the built‑in Windows snapshot mechanism.
  • Many applications (databases, mail servers, etc.) are VSS‑aware and know how to quiesce/flush data when a VSS snapshot is created.
  • It’s generally the most compatible and safest option for system backups, because it’s what Windows and most backup tools are designed around.
  • If VSS on the system is broken (common after some software/uninstalls), you may get snapshot or “shadow copy” errors.
• AOMEI Backup Service
  • This is AOMEI’s own snapshot mechanism, used as an alternative when VSS doesn’t work properly.
  • It can sometimes succeed where VSS fails (e.g. messed‑up VSS writers, odd conflicts).
  • However, many applications are not specifically aware of it, so you don’t get app‑level coordination like VSS writers provide.
  • For a typical home/desktop system (no critical databases running), it usually works fine, but it’s less “standard” than VSS.

Which should you use?

Short version:

• Use VSS as the default if it works reliably on your system.
• Use AOMEI Backup Service only if:
  • VSS fails to create snapshots, or
  • Backups regularly error out with VSS/shadow copy related messages.

For a normal Windows 11 machine with BitLocker, there’s no meaningful difference for BitLocker itself: in both cases, AOMEI is backing up the decrypted contents of the volume. So:

• Encryption state will still be lost on restore (as you’ve seen).
• Switching between VSS and AOMEI Backup Service won’t change that behavior.

Practical suggestion

• Stick with VSS unless you have specific snapshot errors.
• If you ever start seeing VSS errors, test a backup once with AOMEI Backup Service to see if it resolves them.
• Regardless of which you use, occasionally test a restore (to a spare disk, VM, or non‑critical system) to ensure the images are actually bootable and consistent.

So for your setup: keep using VSS as long as it behaves; it’s the more standard and better‑integrated choice in Windows. The BitLocker issue unfortunately won’t change with that setting.

Thanks for the details.


Now for the Sector-by-sector-sector backup, does that support incremental and differential backups? Or is it redundant as the whole disk is encrypted anyway.

 

[Bot]

Thanks for the details.


Now for the Sector-by-sector-sector backup, does that support incremental and differential backups? Or is it redundant as the whole disk is encrypted anyway.

Good follow‑up question – this is exactly where theory and real‑world product limits diverge.

1. In theory: sector‑by‑sector + BitLocker and incrementals

In pure theory:

• A sector‑by‑sector backup of a BitLocker volume just sees encrypted sectors (ciphertext).
• An incremental or differential could still work by only storing sectors whose ciphertext changed since the last backup.
• So it is not inherently redundant: even with encryption, only sectors that actually changed (files, metadata, etc.) would be backed up.

But:

• Encrypted sectors look like random data, so:
  • Compression is usually poor.
  • Even small filesystem changes can affect multiple sectors, so increments can still be relatively large.

So: incremental/differential is still meaningful, just less efficient than on unencrypted, “intelligent” backups.

2. In practice: what many imaging tools do

In many consumer tools (and this is where I need to be careful not to overclaim specifics):

• “Intelligent” backups (file‑aware / used‑sector) usually support:
  • Full, differential, incremental
• Sector‑by‑sector backups are often treated as full‑only jobs, because:
  • They copy every sector, including unused space.
  • Vendors keep the logic simpler and just disable inc/diff for that mode.

For AOMEI Backupper specifically, based on past versions and documentation I’ve seen, it appears that:

• Incremental/differential options are generally tied to the normal “intelligent” backup mode.
• When you enable “Sector by sector backup”, the job is usually treated as a full image each time.

However, I can’t guarantee this for your exact version, so I’d suggest:

• Create a test system backup.
• In Advanced (or the relevant options), tick “Sector by sector backup”.
• Save the task, then see whether:
  • “Backup Scheme” lets you choose Incremental/Differential, or
  • Those options are greyed out/hidden for that job.

That will tell you definitively how your build behaves.

3. Is sector‑by‑sector “redundant” because the whole disk is encrypted?

Not exactly:

• Encryption doesn’t make all sectors change every time; it just makes the content of modified sectors look random.
• So in principle, incremental/differential still saves space vs a full sector‑by‑sector backup.
• But:
  • Images are still much larger than intelligent backups.
  • Compression is poor.
  • SSD wear from restores will still be higher, because a sector‑by‑sector restore has to rewrite every sector that differs, encrypted or not.

So even if AOMEI allowed incremental/differential with sector‑by‑sector, you’d still:

• Write a lot more data than with intelligent backups.
• Keep BitLocker preserved on restore (if you truly backed up the encrypted volume “as is”), but at the cost of backup size and SSD writes.

4. Practical takeaway

• Most likely with AOMEI: sector‑by‑sector = full backups only (no inc/diff), but verify in your UI/doc because versions can change.
• Even if inc/diff were supported, they’d still be much heavier than intelligent backups, just to keep BitLocker intact.
• If SSD wear and image size matter a lot, you may have to choose between:
  • Faster, smaller intelligent backups + re‑encrypting with BitLocker after restore, or
  • Slower, larger sector‑by‑sector backups that preserve encryption.

If you’d like, you can post a screenshot of the AOMEI backup task options (with “sector‑by‑sector” ticked) and I can help interpret what modes are actually available in your version.