A good size for jobs that write to per-VM backup files enabled repositories is 50-200 VMs per job.Īlso, remember that the number of concurrently running backup jobs should not exceed 100. Guest processing and scheduling of jobs that contain multiple snapshots can lead into difficult scheduling situations and jobs spending time waiting for (free) resources. If you split the VMs into multiple jobs, these background processes will run in parallel and thus reduce the overall backup window.īe careful with large jobs when using Storage Snapshots at Backup from Storage Snapshots. For example, a merge process (writing the oldest incremental file into the full backup file) is started after the last VM finishes backup processing. By using multiple VM per job we will reduce management complexity, as it’s much easier to manage a small amount of jobs than trying to manage hundreds of jobs.Ĭonsider that some tasks within a job are still sequential processes. For per VM backup files: up to 300 VMs per jobĪvoid using one VM per job unless is strictly necessary.For per job backup files: up to 30 VMs per job.This site uses Just the Docs, a documentation theme for Jekyll.Ī job is the trigger for the backup and replication process: It defines where, when and how to protect VM data.Ĭonfiguring a job may look easy and straight forward, but there are some consideration to keep in mind, such as: Exclusions, chaining and what method is best for a given backup repository. Restoring VMs to an HPE 3PAR with thin disks.
Backup Repository HA using Windows Storage Replica.
0 kommentar(er)
