Azure-docs: Backups do not work with MySQL-In-App

[somehowadev]

Tried it with multiple new instances to make sure, the error states that it was unable to connect to any of the hosts and to check the connection string, although the connection string is definitely valid.

Just a heads up.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 64f8100c-23f2-3547-840f-dac1d2124225
• Version Independent ID: 3fdd4f69-aaa0-d16d-9615-146257f12ec5
• Content: Back up your app in Azure
• Content Source: articles/app-service/web-sites-backup.md
• Service: app-service
• GitHub Login: @cephalin
• Microsoft Alias: cephalin

[mike-urnun-msft]

@TecumsehSamp Thank you for your feedback! We will investigate and get back to you with our findings.

[mike-urnun-msft]

@TecumsehSamp How did you go about getting the connection string? Is it the same connection string that is defined in d:\home\data\mysql\MYSQLCONNSTR_localdb.txt file? Are you able to use the username & password to sign into phpMyAdmin?

I'm able to setup MySQL in-app backup successfully by using the connectionString from file mentioned above. Screenshot A below shows how i acquired the connectionString (using Console under Development Tools) which i have later added to the Connection strings section under Application Settings (Screenshot B) which then made the MySQL in-app as an available option on Backups blade.

Screenshot A

Screenshot B

[somehowadev]

Yup, connection string worked for phpmyadmin and I got the string from there.

Interestingly, the MySQL connection string environment variable is not set.

(I'll be able to provide more details tomorrow, thanks though)

[somehowadev]

So @mike-urnun-msft

The screenshot above shows phpmyadmin is working, there are 2 servers in that list - both of them with the same connection properties, both connect successfully. I am assuming 1 is from the connection string defined in application settings and the other is phpmyadmin retrieving it directly from the file or a variable (I know it can get login details from somewhere else, forgot where though.)

This is the connection string -

Database=localdb;Data Source=127.0.0.1:50786;User Id=azure;Password=6#vWHD_$

Still seems good, this is the backup configuration -

And on a manual backup.. it fails.

I've checked it numerous time and it's really confusing me. I also tried setting the database to always on to ensure that MySQL is always loaded and running but it still fails.

Any ideas? (By the way, this is with a wordpress install from the marketplace).

[somehowadev]

I've also just tried it on a normal Web app with nothing else installed on it. Same result.

[mike-urnun-msft]

@TecumsehSamp Thanks for the additional details! I was able to repro this issue on my end. We will now look deeper into this issue and take the right course of action. It could be just that the connection string needs to be in different format..

[mike-urnun-msft]

@TecumsehSamp We have assigned this issue to the author to investigate further and take the right course of action.

[somehowadev]

Just wondering if there's any updates on this? (If it helps, I'd say this is a new issue as I've successfully created backups before in the past a few months ago).

[cephalin]

@SunBuild Can you take a look at this?

[cephalin]

Tracking internally at https://mseng.visualstudio.com/TechnicalContent/_workitems/edit/1270698

[somehowadev]

Hey! Is there any update on the status of this?
Thanks.

[somehowadev]

Woops did not mean to close it :/

[msangapu]

Hi @TecumsehSamp I'm looking into this. I'll get back to you.

[msangapu]

Hi @TecumsehSamp - this looks to be a bug on our side. The team is working on a fix. I do not have an ETA at this time.

I see that you're able to use PHPMyAdmin (PMA). Can you please confirm that you're able to make manual backups using PMA - i.e. are you unblocked?

[mike-urnun-msft]

Hi @TecumsehSamp - Thanks again for reporting this issue! As @msangapu mentioned, the fix is currently in-the-works and scheduled to be deployed within ~2 weeks of time. I have re-assigned this to myself and will notify you here as more updates around this issue are made available from our engineering team. Stay tuned!

[mike-urnun-msft]

Hello @TecumsehSamp - The fix should be deployed now. Could you test and see if this now works as expected for you? Thanks!

[mike-urnun-msft]

Hey @TecumsehSamp - Since we haven't heard back, we will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.

[somehowadev]

Nope, it still persists. Getting the same error as before with the same configuration. Connection strings are valid and do work in PMA.

[somehowadev]

Also interestingly I can't reopen it @mike-urnun-msft

[BryanTrach-MSFT]

@TecumsehSamp Please note that you will likely need to delete your backup settings by clicking on the 'reset' button in the backups blade. All settings are cached so this clears out any bad cache. We look forward to your reply.

[somehowadev]

@BryanTrach-MSFT Just reset it & reconfigured it, still failing with the same error code. Not sure yet if it works on new resources though, would need to check tomorrow.

[mike-urnun-msft]

@TecumsehSamp Ok, please let us know if it works with new resource and I'll also test again on my end later today. In case this is something specific to your Azure environment, could you email us at [email protected] with following info:

• Subscription ID
• URL to this Github issue
• Your app name

[somehowadev]

@Mike-Ubezzi-MSFT I'm lucky enough to have different Azure environments I can test this on, it definitely isn't specific to a single environment as I was able to reproduce this in the others.

I was also able to reproduce this with a new resource.

[somehowadev]

@mike-urnun-msft Were you able to reproduce this again? (Tagged the wrong person earlier haha, should have checked better).

[mike-urnun-msft]

@TecumsehSamp I haven't heard back from product group on status & confirmation yet. I'll follow up again tomorrow and update you here ;)

[mike-urnun-msft]

Hello @TecumsehSamp

We have reviewed & discussed this with our product team, and the conclusion is as follows:

"_The user is trying to set up backups in a way that is not intended. In-app MySQL databases will automatically be included in backups. There is no need to manually add a connection string to the app settings, then select the database in the backup settings. In-app MySQL is tightly integrated into App Service, so additional setup steps are not required. However, this makes the setup slightly different from external databases, so there could be confusion regarding the setup process. We should document that in-app MySQL databases are automatically backed up without the additional steps required for external databases. If a user does extra setup by manually adding connection strings for an in-app database, the backups will not work correctly._"

As next step, we have assigned this issue to the content author to communicate this particular detail in this documentation.

Once again, @TecumsehSamp , we appreciate your valuable feedback and contribution in making user experience better for all! Please let us know if you have any further questions regarding this matter. :-)

[cephalin]

@TecumsehSamp I've updated the doc now and it will be published in a few hours. Thanks for engaging with us!

[cephalin]

please-close

[Mike-Ubezzi-MSFT]

@TecumsehSamp We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.

[BilgeKhagan]

Hello All;

I've read all the comments and I saw the problem persists in another way. Although it is said that "in app DB"s are backed-up without any additional setup, the real case differs. When we restore the backup, it doesn't work because of empty DB. We always restore the DB from DB dump manually, otherwise it never works. This means backup procedure does not work as intended and a manual backup process needs to be taken for "MySQL in App" usages.

Any comments?

[mardahl]

Also one just gets this error everyday when the schedule runs:
Failed to backup in-app database. Skipping in-app database backup

Annoying, and confusing to most I suspect!

[juandrn]

It doesn't work in both ways, how you could automate it?, any idea?

[juandrn]

Well, I get an workaround, you can do It creating a WebJobs in the app service and with a php script do the backup using mysqldump, but I don't know if it's very safe

Azure Console Just For Test (You should make a script):
"D:\Program Files (x86)\MySQL\5.7.9.0\bin\mysqldump" inventiolite -P 50618 -h 127.0.0.1 --password=6#vWHD_$ --user=azure --single-transaction > d:\home\site\backup\database_backup_13_pm_09_13_19.sql

Then you can restore with another webjos each 5min or any time, to restore backup in your database.
"D:\Program Files (x86)\MySQL\5.7.9.0\bin\mysql" --port=50618 --host=127.0.0.1 --password=6#vWHD_$ --user=azure --database=inventiolite < d:\home\site\backup\database_backup_13_pm_09_13_19.sql

What do you suggest for It?

NOTA:
Credentials get from here

• d:\home\data\mysql>cat MYSQLCONNSTR_localdb.txt
• my database was "inventiolite"
• I don't paste the php script but if you want it you can tell me.

Ignore it:

_Error:
ignore it -> mysql: [Warning] Using a password on the command line interface can be insecure.
mysql: Unknown OS character set 'cp0'.
mysql: Switching to the default character set 'latin1'._

[somehowadev]

Hey,

Sorry about the late response.

The only thing I can add is that it's been working fine for me over the last few months, it might be worth creating a support request for it or a new issue (as this issue is unlikely to be reopened as it's probably quite different).

Good luck :)

[jourdant]

I think it would really help if we could get the messaging updated to be clearer in the backup pane. It would be great to point out that In-App databases are automatically included in the backup.

This is what I see today:

No supported connection strings of type SQL Database or MySQL found configured in app. This statement originally tripped me up and it wasn't until I did a backup, downloaded the zip and found the MySQL script inside that I realised what had happened. There is a statement saying the database list is coming from the configured connection strings, but my first thought was that the In-App connection string was implicitly defined as an internal concept.

[Mike-Ubezzi-MSFT]

@jourdant There is an additional concept with regard to In-App with App Services. With MySQL you have the option to host a MySQL instance in your App Service hosting plan. This an In-App instance and was made available back in 2016: Announcing MySQL in-app for Web Apps (Windows). This instance is included in the backup of your application.
You now have the option to connect your Azure Web App to an Azure Database for MySQL which is not an In-App instance. This instance requires a connection string configured in Application Settings under Connection Strings.
Are you running an In-App instance of MySQL or do you have an Azure Database for MySQL instance?

[jourdant]

Hi Mike - I appreciate the response.

I have applications using both configurations and can confirm that the Web App backups work with both too. I was just pointing out that the messaging in relation to In-App MySQL was unclear in the Web App > Backups pane in the Azure Portal (or it confused me at least).