I'm facing the following situation, and I'd be really happy to have some help :-)
I have two Esxi 6.5 production servers connected with local gigabit connection.
The goal is to have an automated OneDiff backup with history. My schedule would be to run it 4 hourly.
Backup logic: OneDiff ESXI-A VM's to ESXI-B (Datastore-X) than OneDiff's --onsuccess would call XsiTools on the remote ESXI-B and create XsiTools backup to ESXI-B (Datastore-Y)
This is the tutorial I'm using: https://33hops.com/xsibackup-pro-onedif … olicy.html
It works fine for small machines, but if I try to schedule it evry 4 hour, than the chained XsiTools fails, because for a 700+ GB test VM it can't finish the process. I'd also like to use a weekly rotation, so Its not so universal to make the first OneDiff manually.
It would be nice to see a new switch like --overlap-mode[=killprevious|skipnewrun]
> killprevious: this means, that all the currently running backups are interupted, and the new backup runs.
> skipnewrun: this means, that we let the previous backup to finnish if any.
In the above situation i could set the skipnewrun for the XSITOOLS chained backup, ensuring that the first run can finish.
Is there a chance to have this implemented, or should I fix this issue with other logic?
I agree, since I also requested such feature..
XSIBACKUP-PRO is not a real time, or close to real time, syncronization tool. If you want such feature, you should think about some distributed file system. If you use a small hammer to tear a concrete wall down, you'll soon complain about it, whereas if you use a demolition hammer to nail, you'll soon be dissatisfied too.
You are probably thinking: "as this tool works so well to backup VMs fast, I might use it for something different" => Wrong approach, XSIBACKUP-PRO is a backup tool, use it for your backups and don't try to force it beyond it's limits, as it's boundaries are those of it's own nature.
You can also put it the other way round. If you try to use a distributed file system to keep a real time backup, you will soon discover why that's not such a great idea.
In other order of things, If a OneDiff cycle is taking more than 4 hours, then something is not working as it should and you should stop and find what's going wrong.
If you are using --on-success and --on-error event handlers, then backups should never overlap.