Question

I just made a boneheaded mistake. Thinking I was connected to my local dev db, I accidentally ran the following script against my production SQL Azure database:

DELETE myTable
GO

Is my data gone for good as I fear, or does SQL Azure have some magic “Roll back to 1 hour ago” button?

Is there anything I can do to recover my table’s data?

(BTW, no, I do not have a backup of the database. SQL Azure does not support backups. And, yes, I realize that probably answers my own question… I just hope I’m wrong.)

Answer 1

Update

Azure SQL Database automatically creates backup for all Basic, Standard, and Premium databases. With these backups you can perform Point in Time Restore and recover deleted databases. These backups are also Geo-Replicated to the pair region, so in the event of a regional disaster you could recover your databases with your latest backups (1 hour RPO for V12 servers).

You can learn more about Azure SQL Database’s backup and restore capabilities here: https://msdn.microsoft.com/en-us/library/azure/jj650016.aspx.

There is also a blog on Point in Time Restore and a blog on Geo-Restore and a document about the Business Continuity offerings in Azure SQL Database.

You probably don’t want to hear this, but regular database copies seems to be your only option, i.e., http://social.technet.microsoft.com/wiki/contents/articles/sql-azure-backup-and-restore-strategy.aspx – and must be actively done.

User Error A common cause of database
restores is not from failure or
catastrophe; it is caused by user
error. Either a mistaken command like
DROP DATABASE, schema changes that
don’t get executed right (causing data
loss), or code that corrupts the data.
Creating backups to protect against
user error is the responsibility of
the customer and needs to be taken
into consideration when writing the
backup and restore strategy.

In service update 4 of SQL Azure the
ability to copy the database was
introduced. This feature allows you to
copy a running database creating
another fully functional SQL Azure
database in the same data center. This
is a strategy you can take before
making any changes to the database or
code calling the database to create a
complete backup. One of the nice
things about this technique is that
the copy is a fully functional
database and could be restored
quickly. In fact, restoration might be
as simple as changing the applications
connection string to point to the copy
of the database.

The Transact SQL looks like this:

CREATE DATABASE
destination_database_name
AS COPY OF [source_server_name.]source_database_name
To copy the Adventure Works database
to the same server, I execute this:

CREATE DATABASE [AdvetureWorksBackup]
AS COPY OF [AdventureWorksLTAZ2008R2]
This command must be executed when
connected to the master database of
the destination SQL Azure server.