We were using the SQL Azure Export script as a scheduled task (Mon-Fri; 7am-7pm) for creating rolling backups for the last week. But now the backups started disappearing, so we checked the status on the management portal and got the error location Mon-11 already exists, but the worst part is that the existing backup is also deleted.
So now as a temp workaround we just send the backup command twice, first one fails and deletes the existing backup, and then the second one succeeds.
Can we log this issue somewhere, because I don't think this is expected behavior, either overwrite or fail and DON'T delete the existing backup.
This does seem concerning. Expected behavior is that the export request should fail if the filename already exists. Could you provide some more details on how you are submitting your request? Are you using a shared access key or the full storage account key for your storage account?
Do you have any specific RequestIDs we could take a look at?
We are using the SQL DAC tools (http://sqldacexamples.codeplex.com/wikipage?title=Import%20Export%20Service%20Client) with the following arguments:
-S OURSERVER.database.windows.net -U OURUSER -P OURPASSWORD -D OURDATABASENAME -X -OURSTORAGEPRIMARYACCESSKEY -BLOBURL http://OURBLOB.blob.core.windows.net/FILENAME.bacpac -ACCESSKEYTYPE storage
So we are using the primary access key of our storage. 928f401a-3e7a-4dd9-b11f-246d9983e399 is the request id for the first failed operation.
If the expected behavior is that we can't overwrite existing files then is there any other solution to our problem?
I'm not sure what you are attempting to achieve exactly. Do you want the file to overwrite? To avoid the issue, you could ensure that you submit export requests with a storage location that does not already house a file.
The issue where your file is deleted is not expected and will be fixed in the next service release. Thank you for bringing this to our attention.
We are trying to keep a sliding last 7 days backup, where we named the file Database-Mon, Database-Tue, Database-Wed and it would just overwrite the backup from last week.
We'll change our tool to first delete the file and then start the backup task again.
I see. Once the fix is live then the previous file will not be removed so your plan above will work.