You can run many backups at the same time in BackupChain.
However, there are certain services that do not allow parallel backups. These can sometimes include Exchange Server and SQL Server; it depends on the internal database structure.
Then there could be an error with the Hyper-V backup.
Our recommended method is to define several tasks, and chain them together using the Options tab. Only the first task need to define a schedule. The other tasks then follow one after the other without placing an unnecessary load on the server and the network and without having to define a complicated schedule.
There are other products that send a backup “simultaneously” to other media (parallel or sequential). Usually one main medium is defined and then the others are synchronized. However, we decided against such an implementation because in some scenarios this method is inefficient or risky. For example, damage to the main media is passed on to all other media. So there is no isolation, e.g. from vandalism, ransomware overwriting backups, and disk and file system damage. In the case where the second media is very slow compared to a local disk target as the main media, e.g. network backup or cloud backup, the task is delayed unnecessarily. With multiple backups that run in parallel, the network will be unnecessarily overloaded and this may adversely affect other services. And then the question arises, what happens when the main media becomes temporarily inaccessible? Should the task continue to back up to the second media and what should happen if the main media comes back online after 3-4 backups?
For these reasons and several others, we therefore recommend several tasks with isolated target media, which can either be set separately in the schedule or linked together. By doing so, there are no dependencies between the backups and there is no need for complex synchronization between media.