In Veeam Backup & Replication 7.0, servers running on 64-bit platforms will automatically use a true 64-bit Veeam transport service. This offers more flexibility in job size — in particular, larger jobs will not lead to memory problems of that kind.
(Consider that if using a 64-bit repository server, backup size will be limited primarily by the actual available memory in the system, and other OS level limits, such as maximum file size.)
In earlier versions, Veeam transport service deployed on repositories was a 32-bit process (even on 64-bit architectures), limiting the memory available to the process. This could lead to problems with very large backup jobs, either failing with memory allocation errors during backup, or even during recovery - when attempting to mount restore points.
Though it might be possible to add virtually any number of VMs of any size into a single job (using the parallel processing function), there are several practical reasons to break jobs into more manageable chunks, as noted below:
•Running a full backup of an extremely large job requires a full backup of all VMs in the job, which can be very resource-intensive on the VMware environment.
•Very large backup files are more difficult to manage and relocate when moving to a new repository or when tight on space.
•Restoring VMs from tape needs a staging repository for the files that should be restored back to disk, and having very large backups can lead to long restore times and require large amounts of staging disk space.