For example, user creates snapshot policy for FastBack client,
and the snapshot is scheduled as starting at 11PM. But the snapshot
is executed 4times, although those snapshot are running as incremental and all
snapshot were completed successfully.
1st time 23:00
2nd time 23:06
3rd time 23:13
4th time 23:19
This is for FastBack retry mechanism:
When a snapshot fails, all snapshots that are running using the same Job
Schedule will be retried even if they completed successfully.
In the case here the C and D on client_A completed but the snapshots on
client_B failed and what we see are actually the retries of the entire
job schedule that started at 23:00
The mechanism is there to try and help with data consistency:
The idea behind it is that all volumes that are backed up at the same time
probably have some kind of connection between them. For example:
with Exchange usually you have volume/s with the data (edb) and volumes with the logs. If the data on the volumes is connected, you need to run snapshot from the same
point in time for all the connected volumes in order to recover the data.
If one volume fails, and the rest complete and the one the failed
runs again and complete (or fail), you cannot use any of the snapshots
since they did not start at the same time.
Resolving the problem
This can be avoided by creating more Job schedule and dividing
the clients / policies accordingly.