Loss of precision MySQL (flexible) Backup/Restore timestamp

[crussell52]

MySQL flexible server backups are stored with microsecond precision, as can be seen in the "restore from full backup" dropdown in the portal and the parameters of the ARM template from a "fast restore" operation in the portal. However, the JS date object used by the SDK has millisecond precision. This loss in precision causes problems when trying to restore from a specific backup.

In our case, our automation retrieves the list of available backups and selects the most recent one to execute a restoration from. We found the restore operation to take significantly longer than when doing a "restore from full backup" (aka "fast restore") from the same backup through the portal. Shifting the restore point by a small amount into the future resolved the issue.

Our conclusion is that the loss in precision in ServerBackup.completedTime is causing Azure to select the previous backup and making up the difference with replication logs because we end up requesting a restore point that is <1ms before the actual backup completion date

Even if an exact timestamp could be obtained, the Server.restorePointInTime also uses a Date object which lacks ability to specify an exact backup moment.

For these two interfaces, it would be good to have a string property that represents the exact backup timestamp. It would also be good if there was documentation and/or samples that explain the impact of this loss of precision when restoring from a specific backup.

[crussell52]

Just confirmed through testing that adding 1ms to the ServerBackup.completedTime is enough of a shift to overcome loss of precision. (Makes perfect since since lost precision is microsecond)

Early workaround testing had it shifted by 10 seconds, but can lead to RestoreTimeIsInFuture error if the backup is very recent. That should be very unlikely with 1ms.