Hey everyone,
I really like the Veeam Incident API approach, however I think there could be more "action triggers" when something gets passed on to the Incident API.
As of now it only triggers a Quick Backup, which is an incremental backup based on a VM in an existing backup job. If a backup job for the VM does not exist, quick backup is terminated.
I'm thinking of 2 more ways what an "action trigger" of the Incident API could / should do in the following order.
1. Trigger a Storage Snapshot. All the necessary information is available inside VBR such as on which datastore a VM resides. If a integrated storage or USAPI storage is connected why not trigger a Storage Snap to protect the VM at the source. Most vendors have immutable snapshot or any sort of "retention lock" in place which makes it even more meaningful.
2. Trigger a replication of that VM to for an example an isolated recovery environment, or trigger the storage snapshot to replicate it across the connected storage arrays.
Thanks !
-
falkob
- Veeam Vanguard
- Posts: 87
- Liked: 31 times
- Joined: Sep 28, 2017 7:47 am
- Full Name: Falko Banaszak
- Contact:
Feature Request - Incident API More Triggers
VCP6.5-DCV, VCP6-DCV, VMCE, VMCA, Veeam Vanguard, VMware vExpert
https://www.virtualhome.blog
https://www.virtualhome.blog
-
Egor Yakovlev
- Product Manager
- Posts: 2666
- Liked: 767 times
- Joined: Jun 14, 2013 9:30 am
- Full Name: Egor Yakovlev
- Location: Prague, Czech Republic
- Contact:
Re: Feature Request - Incident API More Triggers
Hi Falko,
Interesting suggestions. I've added them to the list of items to consider for future improvements. Your points raise some important questions, such as how to prioritize one action method over another and a possibility to handle per-workload granularity. These are aspects we’ll need to carefully evaluate as we look at expanding the Incident API.
Thanks again for your valuable input!
Interesting suggestions. I've added them to the list of items to consider for future improvements. Your points raise some important questions, such as how to prioritize one action method over another and a possibility to handle per-workload granularity. These are aspects we’ll need to carefully evaluate as we look at expanding the Incident API.
Thanks again for your valuable input!
Who is online
Users browsing this forum: Bing [Bot], Semrush [Bot] and 440 guests