Feature Request - Move Backup Speed Increase

[ryan.christensen]

When moving backups from a repository that is not object based, wouldn't it be faster to move servers one by one instead of all at once? I can only imagine that it's thrashing the disks trying to move all at once.

[david.domask]

Hi Ryan,

Move Backup will respect the concurrent task limits set on source/target repository, so if there are concerns about the workload on the repository you can set the concurrent task limit lower on the source OR target repository, and Backup Move will honor the restrictions.

As for is it faster to go sequentially, depends on the storage itself -- a lot of storage can easily support quite a number of streams with stable performance for each stream, so it will largely depend on the environment.

Are you seeing issues where Backup Move is non-performant compared to backups/restores?

[ryan.christensen]

It feels like it's slower but I'll need to do some testing. It makes sense that it respects the concurrent task limits. I might try lowering that to 1 on the target repo and see how it handles compared to the default of 4.

Thanks

[mkretzer]

Concurrency is essential and very important! On RAID systems with hundreds of disks one sequential stream will only put load on a few disks.
What we did is to limit only the target for example to 20 streams for moving and keep the source streams to 256 or more.