Symptoms
After a backup, you find in logs information that the backup switched to sector-by-sector mode. This sector-by-sector mode is slower than the default method.
The messages in the logs look similar to these:
Error code: 46
Module: 7
LineInfo: a5695862aaf8e75e
Fields: PartitionId : 219
Message: Forced sector-by-sector mode.
--------------------
Error code: 28
Module: 7
LineInfo: 89d94b01b483dcca
Fields:
Message: Run list is corrupted.
OR
--------------------
Error code: 46
Module: 7
LineInfo: a5695862aaf8e75e
Fields: PartitionId : 227
Message: Forced sector-by-sector mode.
--------------------
Error code: 22
Module: 7
LineInfo: 89d94b01b483dcdb
Fields:
Message: Block bitmap is corrupted.
OR
--------------------
Error code: 46
Module: 7
LineInfo: a5695862aaf8e75e
Fields: PartitionId : 997
Message: Forced sector-by-sector mode.
--------------------
Error code: 37
Module: 7
LineInfo: 89d94b01b483de5a
Fields:
Message: Index is corrupted
OR
--------------------
Error code: 46
Module: 7
LineInfo: a5695862aaf8e75e
Fields: PartitionId : 845
Message: Forced sector-by-sector mode.
--------------------
Error code: 24
Module: 7
LineInfo: ef8b1618a4c0dd9c
Fields:
Message: MFT bitmap is corrupted.
OR
Event code: 46
Module: 7
LineInfo: a5695862aaf8e7b0
Fields:
Message: Forced sector-by-sector mode.
--------------------
Event code: 11
Module: 7
LineInfo: 6b426cba4c49b72b
Fields:
Message: FAT is corrupted.
OR
Error 0x70036: The file system is corrupted. Fast incremental/differential backup is disabled and file filters are not effective.
2020-08-04T02:55:34:665-05:00 20476 I0007002E: service_process(30956): Error 0x7002e: Forced sector-by-sector mode.
| trace level: information
| line: 0x8ba4fa0bac28c2ba
| file: d:\377\core\resizer\archive3\backup_partition.cpp:1383
| function: resizer::Archive3ImageBuilder::BackupPartitions
| volume: C:
| fstype: NTFS
| $module: disk_bundle_vsa64_23094
|
| error 0x70018: MFT bitmap is corrupted.
| line: 0xef8b1618a4c0dd9b
| file: d:\377\core\resizer\ntfs\fs_ntfs_misc.cpp:61
| function: resizer::NTFSProcessor::FileRecord::Load
| $module: disk_bundle_vsa64_23094
olution
Common solutions
These solutions can be applied to all the issues described below and we recommend to use them before any further step.
- Check all the filesystems inside the (guest) OS with chkdsk, see solution #1 "Run list is corrupted" for more details.
- (!) Please keep in mind that some filesystems like SystemReserved or RECOVERY can be hidden and one has to assign a disk letter to such a partition to make it accessible for chkdsk.
- For virtual machines: reinstall VMWare Tools or Hyper-V Integration Services inside the guest OS and reboot the system.
If these steps don't resolve the issue, proceed with the following solutions.
Specific scenarios
1. Run list is corrupted
Cause:
First of all there may be a problem with the file system inconsistency inside the backed up machine, so the Acronis product is unable to properly read from it and therefore starts backing up the machine in sector-by-sector mode.
Solution:
To resolve this you should perform file system check via embedded Windows utilities. Please run CHKDSK utility on all the logical volumes inside the machine:
- Go to the Command Prompt (Start -> Run -> cmd);
- Enter the command: chkdsk DISK: /r
(where DISK is the drive letter of the partition you need to check.)
(!) Checking the C: drive may require you to reboot the machine, so if reboot is not possible at the moment run chkdsk without "/r" parameter. If no problems are revealed then you won't need to run "chkdsk /r" - in this case check the below sections for possible workaround.
2. Index is corrupted and MFT bitmap is corrupted
Cause:
These messages may appear in rare cases when the machine is under high load during the backup. In these cases there may be a situation when there is data recorded in NTFS journal which is not yet flushed to the volume - the file system therefore is recognized as corrupt since Acronis products are unable to read the NTFS journal properly and require that the data is flushed to disk in order to read from it. This situation forces the sector-by-sector backup mode.
Workaround:
The problem is caused by specific VSS writer which is installed by default in Windows 2008 R2. The writer is called "Shadow Copy Optimization Writer" (http://msdn.microsoft.com/en-us/library/bb968827%28VS.85%29.aspx#shadow_...). It performs VSS snapshot modifications which are causing the issue described above and therefore the solution is to disable this VSS writer from processing by VMware tools. Please check the following VMware article on how to disable specific VSS writers: https://kb.vmware.com/s/article/1031200
In short you should create vmbackup.conf %ALLUSERSPROFILE%\Application Data\VMware\VMware Tools\ on the Windows 2008 R2/SBS 2011 VM which is being backed up, open this file in Notepad editor and add the following line:
Shadow Copy Optimization Writer
After that restart VMware Tools Service and try to back up this VM once again.
The above described method is in fact a workaround and you should either use this method or ignore these messages. If you ignore this issue please note that in some cases files/folders recovery from such backups may not be possible, however it will still work in most cases even despite this message (it is a random behavior). You can still recover the entire VM from these backups or run it from backup (the Run VM from Backup feature) for granular recovery purposes.