Cannot open backup device - SQL Server on-premise backup database to Azure storage - sql

I have a database running on an on-premise SQL Server instance. I've set up a SQL agent to backup the database every night and store in a container in Azure. However, I'm seeing the following error after the job runs:
Message
Executed as user: NT SERVICE\SQLSERVERAGENT. Cannot open backup device 'https://mystorageaccount.blob.core.windows.net/mystoragecontainer/20200102/MYDATABASE_0.bak'. Operating system error 50(The request is not supported.). [SQLSTATE 42000] (Error 3201) BACKUP DATABASE is terminating abnormally. [SQLSTATE 42000] (Error 3013)
The Azure storage account is Storage (general purpose v1).
SQL Server 13.0.5233.0
Microsoft SQL Server Management Studio 14.0.17213.0
Microsoft Analysis Services Client Tools 14.0.1016.232
Microsoft Data Access Components (MDAC) 10.0.14393.0
Microsoft MSXML 3.0 6.0
Microsoft Internet Explorer 9.11.14393.0
Microsoft .NET Framework 4.0.30319.42000
Operating System 6.3.14393
Is there a way of configuring NT SERVICE\SQLSERVERAGENT to connect to the Azure storage container?

All the comments are valid to a certain extent. I finally fixed (term used loosely) backing up my SQL Server database to an Azure storage container using SAS (shared access signature) credentials.
Deleted the existing credential in SQL Server (under Security > Credentials)
In Azure, created an access policy under Storage Account > Container. It's important to define start and expiration dates/times, and time zones along with read, write level.
In Azure, Generate a SAS token for the container. Ensure you set the appropriate start and expiration dates/times along with the timezone. Don't rely on just UTC.
Upload a file to the container to make sure it's all ok.
In SQL Server, create the credentials. The secret should be the SAS token without the preceding ?, so just "sv=...." .
IF NOT EXISTS
(SELECT * FROM sys.credentials
WHERE name = 'https://mystorageaccount.blob.core.windows.net/mycontainer')
CREATE CREDENTIAL [https://mystorageaccount.blob.core.windows.net/mycontainer]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
SECRET = 'sv=_my_sas_key_without_?';
Backup the database. The URL and container must match with the credentials - in this case, https://mystorageaccount.blob.core.windows.net/mycontainer .
BACKUP DATABASE [mydatabase]
TO URL = 'https://mystorageaccount.blob.core.windows.net/mycontainer/mydatabase_03012020120400.bak'
WITH FORMAT,
COMPRESSION,
STATS=5,
BLOCKSIZE=65536,
MAXTRANSFERSIZE=4194304;
GO

This seems like access related issue.To be able to back up to Azure Blob Storage, your backup command must have a valid credential that has access to the blob storage. This can be done in two ways:
Review your credentials, make sure your access key is correct and, if you’re using SAS, make sure that the access policy is defined and you are pointing to the correct container that it has access to. For more information on URL backups as well as script samples, please refer:
https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/sql-server-backup-to-url?view=sql-server-2017
Shared Access Signature
Identity and Access Key
Additional reference:
https://blog.pythian.com/how-to-fix-sql-backup-to-url-failure-operating-system-error-50/
Hope it helps.

Related

Why can't my Azure app service backup connect to my Azure SQL database?

I am experiencing a problem configuring the backup of an SQL database using Azure.
I have web application and an associated Azure SQL database. The app connects to the DB no problem. I have pasted the connection string provided to me by the Azure UI (Home -> SQL Databases -> My SQL Database) into the connection strings section of the configuration for the App Service (Home -> App Services -> My App Service -> Configuration). I created a backup of the App Service (Home -> App Services -> My App Service -> Backups -> Configuration) and ticked my connection string to be back up my database.
After about 20 minutes, the backup fails with the error:
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - No such host is known.)
I can connect to the database from the SQL Server Management Studio running on my laptop, and from code running on my laptop, using the server, username and password from the connection string, why can the backup not connect to the database?
Many thanks for any advice.
Linking the same question asked on MSDN: Azure SQL Database Backup Fails, cannot connect to the database.
Please see the Requirements and Restrictions details where this functionality is not supported, which I have listed below the applicable items that apply to your scenario:
The Backup and Restore feature requires the App Service plan to be in the Standard tier or Premium tier. For more information about scaling your App Service plan to use a higher tier, see Scale up an app in Azure. Premium tier allows a greater number of daily back ups than Standard tier.
You need an Azure storage account and container in the same subscription as the app that you want to back up. For more information on Azure storage accounts, see Azure storage account overview.
Backups can be up to 10 GB of app and database content. If the backup size exceeds this limit, you get an error.
Using a firewall enabled storage account as the destination for your backups is not supported. If a backup is configured, you will get failed backups.
If none of the above apply to you, then the issue is an IP Address issue in that you need to enable "Allow access to Azure services" in the firewall for your Azure SQL (logical) Server.
Additional troubleshooting can be performed by leveraging Application Insights to capture the backup failure event and then drill into the collected log detail to see what the specific error is.

Passing MSI token to flyway command line

When running the 'migrate' command of the flyway, the standard way to access DB is by providing user and password. In my case, it's Azure SQL DB and instead of user/password I have only MSI token. Is it possible to pass the token to the command line? Looking at the parameters of the 'migrate' command I couldn't find anything like that.
Azure Active Directory MSI Authentication is supported and please see the Microsoft documentation as it has more details about how these work with JDBC URLs, (link) to download the driver and the applicable connection string properties and client requirements but please note:
Supported since driver version v7.2, authentication=ActiveDirectoryMSI can be used to connect to an Azure SQL Database/Data Warehouse from inside of an Azure Resource with "Identity" support enabled. Optionally, msiClientId can also be specified in the Connection/DataSource properties along with this authentication mode, which must contain the Client ID of a Managed Service Identity to be used to acquire the accessToken for establishing the connection.
You could run this from an Azure AD Federated on-premise host or Azure host using the following java client example and then run the migrate command.

Azure SQL PaaS - Limitations

We are trying to evaluate possibility of migrating our in-house SQL DB server to Azure SQL as a PaaS.
Our legacy windows application which is written in VB6 and now running on VB.NET Framework 4.5
Clarifications I need if I migrate only DB server to Azure:
We use both trusted / credential based SQL connection from our desktop application to connect to SQL DB. If we migrate to Azure SQL, will it support trusted connection which should authenticate current organizations NT user?
We have lot of cross DB queries, do we need to face any challenge to use the queries as it is?
Run time we take a DB backup / restore for some business cases. Does this work?
Are there any restrictions on number of admin users on Azure DB?
Probably yes if you sync your local AD with an AAD (See: Use Azure Active Directory Authentication for authentication with SQL Database, Managed Instance, or SQL Data Warehouse)
Azure SQL Database (PaaS) doesn't support cross DB queries by default - you have to setup / use Elastic Query for that.
Yes, you can take a DB backup at runtime and also restore it. There is also a point-in-time restore feature available. See: Learn about automatic SQL Database backups.
I think you can only specify one server administrator (at least within the portal) but I doubt you will reach any limit on db users.
Instead of using the single database SQL Server PaaS service you should also consider using Managed Instance (preview)
You will have to extend your active directory to Azure active directory to keep using trusted connections. You will learn how to do it on this documentation and this one.
On Azure SQL Database you have elastic queries that allow you to run cross database queries. Learn how to create elastic queries here.
You can create bacpacs (export your databases) to Azure Storage or to on-premises location very easy.
You can configure one Server Admin or one Azure Active Directory Admin (it can be a group) for your Azure SQL Server. However, at the database level you can add many database users to the dbmanager role. You can have more information about this topic here.

Internal error import BACPAC file to windows azure sql database

I am using MSSQL2014 version CTP2.
Running my databases through Windows Azure SQL Database management.
I've created a BACPAC file via MSSQL of my local database and want to import it to Windows Azure.
I create the BACPAC file and upload it to my BLOBSTORAGE container.
In Windows Azure click SQL DATABASES
Bottom left click New
Click IMPORT
Choose my BACPAC URL which is the file contained in my BLOBSTORAGE
Name the DB and choose the server
Click the tick
I then get this error:
Error encountered during the service operation. Could not import
package. Internal Error. The database platform service with type
Microsoft.Data.Tools.Schema.Sql.Sql120DatabaseSchemaProvider is not
valid. You must make sure the service is loaded, or you must provide
the full type name of a valid database platform service. Internal
Error. The database platform service with type
Microsoft.Data.Tools.Schema.Sql.Sql120DatabaseSchemaProvider is not
valid. You must make sure the service is loaded, or you must provide
the full type name of a valid database platform service.
I can create a new database via Windows Azure which is fine but I'm trying to get my DB up because it has all my data in it.
What am I doing wrong?
I believe the issue was that I needed to assign the same DB owner to my db on my local machine as the one that was setup on my azure setup.

Database Replication MSSQL 2000 to 2005

I am trying to replicate a database from SQL server 2000 to 2005 they are located on two different servers both running Windows Server 2003 R2. Im am using SERVER1(SQL2000) as the Transactional publisher and distributor and SERVER2(SQL2005) is the subscriber. I can set up the publication and subscription but when I try to syncronize them I get the following error:
SERVER1-TestReplication-TestReplication-IBSCNVII-ReplicationCNVII_2-99956FE2-402A-48D5-B801-2CBADF12BD3E has server access (reason: Could not obtain information about Windows NT group/user '', error code 0x5. [SQLSTATE 42000] (Error 15404)).
Do I need to add my domain user to a certain user group on server? Any ideas?
0x5 means "access denied" and that you're not allowed to query active directory user information. Likely, the sql server service account does not have proper domain privileges to perform look ups in AD. This could be caused by an account password simply being expired and therefore not enabling SQL to validate against AD or some other issue like services running as local system and not a domain account.
I would recommend confirming that both SQL servers are using a valid domain account and not something like local system. Then check that that domain account isn't locked up or expired.
make sure that the service account you are using to execute the replication has the appropriate rights to both your SQL servers
Aye, check your SqlAgent account in services.msc. Make sure it is a user with rights (in the domain and in SQL). If that fixes it, make sure you lookup the minimum rights required before you go into production.