Example scenario:
Let's say we have more than VM in a job and job runs every X hours.
If backup job runs for longer than X hours for whatever reason (network congestion, source/target is having a bad day, really long sythetic/full, more changes than usual, various transitional issues), than the next start is skipped and RPO targets might be missed. Even if one VM was problematic (for example one huge file server with lots of changes among many small app servers), any other VMs in job are affected as well.
Option 1: Start new instance of job and backup any VMs except the ones that have a job still running. Restore point for some VMs is better than none. Original job will keep running to completion/failure. Sounds almost like one VM per job but with less overhead.
Option 2: Resnapshot VM to gather changes for a new incremental/full from CBT. If previous job eventually completed than we would eventually meet RPO. If original job failed than we've done some extra work but haven't lost anything (compared to current situation).
Either option might lead to resource congestion but would be really helpful in some scenarios.
-
- Service Provider
- Posts: 368
- Liked: 120 times
- Joined: Nov 25, 2016 1:56 pm
- Full Name: Mihkel Soomere
- Contact:
-
- Veeam Software
- Posts: 21072
- Liked: 2115 times
- Joined: Jul 11, 2011 10:22 am
- Full Name: Alexander Fogelson
- Contact:
Re: Feature request: multiple running instances of the same
Thanks for the feedback, but either option might result in backup chain becoming a mess as well as other unpredictable consequences. To avoid them, we do not allow processing of the same VM twice at the same time.
Who is online
Users browsing this forum: amiura, MaartenA, Semrush [Bot] and 127 guests