Everyone else is just telling you to do things in a way that is different, and while they are correct (you should use a unit.d/systems script for this depending on your distro), I’m going to actually answer your question since I know sometimes you just need a quick and simple way.

Depending on your version of cron, it may support special statements instead of the * * * * * notation for time.

The one you want is @reboot. Replace all entries of the schedule syntax with that, including the @, and the command will be executed only once when the system boots up.

Use that to start a script that checks for network connectivity on a loop with a sleep statement. Break the loop when you have connectivity, then execute your command, and exit the script.

Don’t ignore the correct way though. You’re better off executing this as a systemd (or equivalent) script. It’s barely more effort, and has the benefit of some nice built in logging and integrations.

I have some bad news…

My tried-and-tested method has saved my (company’s clients) ass a few times.

Every Mysql/MariaDB server has at least one replication target. This replicant is not used for access by the infra, and can be paused, restarted, etc with no issue and is configured with this in mind.

We run a mysqldump on the replicant. Depending on the resiliency required, we store the dump on the replicant and/or a third location.

The tools differ, but the practice applies to pretty much every database system and the database has the benefit of not being interrupted during the backup (replication is paused during the backup, and resumed after completion). This also has the benefit of already having replication configured, and adding a secondary redundant instance you can swap out for the master (or using the backup replicant in a pinch) means disaster recovery is much faster.

Also, I dislike many things about Azure’s offerings, but their Flexible Database for MySQL does the above for you as one nicely packaged solution for a reasonable-but-not-cheap price.