Known Issues in Backup

Lindenberg Software Backup limitations on Windows 7 / Windows Server 2008 / Windows Home Server

• On these operating systems the Virtual Disk API does not support all the features required by the backup service and thus the option to run a backup service is not available in the configuration UI. On the same operating systems and also because of limited operating system support for virtual disks plus lack of support of Server Message Block 3.0 encryption, the "Mount" button is not supported. Otherwise they are supported as clients.

Minor Issues (these are likely to be addressed depending on user's needs. Some are just noteworthy and not really bugs)

• When backing up multiple disks, the display in Lights-Out 2 is not correct after the first backup finishes. The problem is fixed in Lights-Out 3, which also shows the disk backed up in the backup list.
• Systems using Instant Go (formerly known as Connected Standby, and also called Modern Standby in Microsofts documentation) may go to sleep state during backups, especially when running on battery. When connected to power, backups usually succeed.
• Occassionally Windows Task Scheduler may not start the backup at the configured point in time but later. The exact situations are probably only known to Microsoft, but usually it happens on battery if the battery is already low and there is a great risk that backup would not succeed anyway.
• There is no support for scheduling multiple configurations on the client, e.g. for different disks or different servers. Note however that multiple disks are supported and multiple servers are possible via Resilience Setup. Actually multiple configurations can be done with some scripting, please let me know if you are interested.
• There is no integrated means to pause a backup schedule during e.g. vaccation. For support of more complex scheduling I recommend to use Lights-Out 2.0 or higher.
• Locked Bitlocker encrypted volumes will cause the backup of the disk to fail after retrying several times. This is primarily because switching between unlocked(mounted) status and locked(unmounted) status is like an initial backup of the respective volume - which does not make any sense. On the other hand, skipping the volume without reporting an error also does not make sense. Recommendation is to use a) auto unlock feature of Bitlocker, b) not to include removable drives in an automated backup configuration (as Bitlocker requires the user to login first before triggering the auto unlock, see Bitlocker Auto-unlock).
• Disks that are not supported -- see Technical Limitations below -- are only reported after trying a backup.
• There is no user interface to change the default configuration of virtual machines. Of course you can change them manually using Hyper-V-Manager. It is also possible to use Powershell configuration scripts via the registry - let me know whether you are interested.
• Virtual machines may become broken as backups are merged, and virtual machines created by Backup are not cleaned up automatically.
• NTFS volumes larger than 8TB may not work with USN Journal enabled (see potential DiscUtil issue).

Technical Limitations of Lindenberg Software Backup

• Lindenberg Software Backup does not support backing up a disk, where the start of any partition is not aligned to a 4KB boundary. Partitions that are not aligned do have a significant negative impact on overall system performance, not just on Lindenberg Software Backup. Thus you should take the time to change alignment of partitions in that case. A tool that supports partition alignment is AOMEI Partition Assistant. I cannot comment on the relevance of alignment beyond 4KB boundaries, but 4KB alignment is the minimum. Note that the free "Standard" version does not support alignment, but any of the other versions does, and trial versions exist.
• Lindenberg Software Backup does not support backing up a disk, where a NTFS volume uses a cluster size smaller than 4KB. A volume with a smaller cluster size is very likely on a historic disk, as Microsoft's documentation on NTFS does not list smaller cluster sizes any more.
• As Lindenberg Software Backup uses virtual hard disk (vhd) format for backup images, it inherits the limit of 64TB for .vhdx or 2TB for .vhd from the file format. Note that .vhdx is the preferred and recommended format, and that Lindenberg Software Backup switches automatically to .vhdx if the disk size exceeds 2040GB or the disk uses a different sector size than 512 bytes.
• There is a 64TB limit for volume shadow copy service inherited from Windows. Essentially this limits the size of volumes of which you can do consistent backups without taking them offline or locking them against other applications (which Lindenberg Software Backup does in case volume shadow copies are not available).
• There is a limit of 2GB on the user data virtual memory address space of a single process in any 32-bit-Windows (see here). Obviously Lindenberg Software Backup needs memory for lots of objects, but the biggest objects are the volume bitmaps, and unfortunately it needs that twice during processing. Thus in case you cross roughly 1GB on the volume bitmap size, Lindenberg Software Backup will run out of memory. 1GB translates to roughly 8,000,000,000 bits or clusters. That number is higher than the maximum number of clusters on any NTFS volume (see here), but with ReFS and 4KB cluster size that translates to roughly 32TB maximum volume size. Note that this is the hard limit, you may run out of memory a lot earlier, see https://stackoverflow.com/a/1088044 as .NET also needs memory. I have seen out-of-memory-exceptions with a NTFS 10TB disk. Also note this limit does not apply to 64-bit versions of Windows, which is therefore recommended.
• There is a limit on array sizes with .Net on 64-bit-Windows. Lindenberg Software Backup uses an array of 32bit-integers to represent the volume bitmap. Thus the number of clusters on a ReFS volume is limited to 68,719,476,704 clusters, or the volume size to roughly 280TB at 4K cluster size or 4.5PB at 64K cluster size, but you are guaranteed to run into the 64TB limits above first.
• There is a limitation in Lindenberg Software Backup on the maximum number of clusters supported of a ReFS volume. On Windows 32bit, the limit is because neither a single object nor the process can exceed 2GB of memory. On Windows 64bit there is a limit on array sizes, and Lindenberg Software Backup uses an array of 32bit-integers to represent the volume bitmap. Thus the number of clusters is limited, which in turn limits the volume size depending on the cluster size used. Also, for USN Journal processing, Lindenberg Software Backup needs two copies of the volume bitmap, and of course also more memory for buffers and other data.

  	Maximum number of clusters	Maximum volume size at 4KB cluster size	Maximum volume size at 64KB cluster size	virtual memory required (two copies)
  Windows 32-bit	17,179,869,184	70.368,744,177,644 - 70TB	1,125,899,906,843,620 - 1PB	4GB - in essence you will run out of memory around half the size
  Windows 64-bit	68,719,476,704	281,474,976,579,584 - 280TB	4,503,599,625,273,340 4.5PB	16GB (not considering buffers and other data)

  With ReFS there is only a choice of cluster size 4KB (default since Windows Server 2016/Windows 10) or 64KB (default with Windows Server 2012), and then volume size limit are shown in the table above. Note that Microsoft recommends 4KB clusters.
  NTFS volumes are not affected by that limit, as NTFS has a cluster size limit of 4,294,967,295 clusters and also the cluster size increases with volume size.

Release Notes

Important changes in version 1.3

• USN Journal is supported with ReFS starting with version 1.3. Due to incomplete journal information on windows volumes, journal is disabled for windows or boot volumes. For details please refer to Use USN Journal in Configuration

Bug Bounty Program