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.

Major Issues (these are very likely going to be addressed soon)

• USN Journal is not supported with ReFS yet. Because of that, backing up large, non-SSD ReFS volumes is a time consuming operation. With SSD, ReFS is still very practical, and in particular recommended for use with Hyper-V.
  Update May 2019: this is about to be resolved very soon. If you want to test the feature please let me know.

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.
• 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.

Technical limitations of Lindenberg Software Backup

• 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 on 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 may 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.
• 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 32-bit Windows, the limit is because neither a single object nor the process can exceed 2GB of memory. On 64-bit Windows 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.
• There is a limit of 140TB on the size of a Sqlite database (#12) used for USN processing (at present ReFS only). Obviously you will hit the 64TB limit above first. At present there is no experience on how big the Sqlite databases can grow in practice, but the assumption is that typically they are smaller than the hash files used for delta detection.

Bug Bounty Program